Inconsistency in Python's Comparisons

[Tim Peters]

[Dietrich Epp]
>> I wouldn't say comparing different different types is necessarily an
>> error, though.

[Erik Max Francis]
> It's guaranteed to be consistent, and sort is guaranteed not to go
> nuts (as someone else pointed out).  The ordering is defined to be
> consistent, although it does not define a well-ordering, and
> furthermore need not be the same between different implementations
> (or even different implementations).  It may not be an error, but
> there's no reason for it to be a total ordering.

When the language reference manual says "consistent" here, Guido did indeed
mean "total ordering", including transitivity and trichotomy.

There are (and always have been) goofy cases where comparisons among objects
of builtin types don't meet this promise, where

    a < b < c < a

is true.  Such cases are considered to be bugs, although at this point I bet
Guido is getting more inclined to consider the promise of a consistent
ordering across all objects of builtin types to be an error in Python's
original design (it's a promise that's never been met, despite several
rounds of pure hackery to try to meet it -- "if the implementation is hard
to explain, it's probably a bad idea", and the implementation of comparison
at this point has become absurdly hard to explain in full detail).