[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects tupleobject.c,2.48,2.49

[Tim Peters]

[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.)