[Tim] > BUG ALERT: The tuple (and list) richcmp algorithm is arguably wrong, > because it won't believe there's any difference unless Py_EQ > returns false for some corresponding elements: > > >>> class C: > ... def __lt__(x, y): return 1 > ... __eq__ = __lt__ > ... > >>> C() < C() > 1 > >>> (C(),) < (C(),) > 0 > >>> > > That doesn't make sense -- provided you believe the defn. of C > makes sense. [Guido] > I think in this example the problem is with C, not with the tuple > algorithm. I can live with that. > The question is, what are you going to do otherwise? You > could test for < first, == second -- but that means twice as many > comparisons, and for reasonably-behaved items it makes no difference > at all. The question remaining is how much of this list/tuple richcmp behavior is guaranteed by the language and how much is just implementation-dependent fuzz. For a more vanilla example, I removed the EQ/NE "lengths differ?" tuple richcmp early-exit test because I never found code that made it trigger. (but tons of code that gets there without triggering). But this has semantic implications too: an implementation without the early exit may call user-defined comparison routines that raise exceptions when comparing tuples of different lengths now. Do you care? (I don't.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4