
[Andrew Koenig]
I'm beginning to wonder if part of what's going on is that there are really two different concepts that go under the general label of "comparison", namely the cases where trichotomy does and does not apply.
In the first case, we have a total ordering; in the second, we have what C++ calls a "strict weak ordering", which is really an ordering of equivalence classes.
I'm afraid Python people really want a total ordering, because that's what Python gave them at the start (ya, I understand the long vs float business, but nobody in real life ever griped about that). It's a curious thing that the *specific* total ordering Python supplied changed across releases, and nobody complained about that(*). Also curious that, within a release, nobody complained that the specific total ordering can change across program runs (comparisons falling back to comparing object addresses are consistent within a run, but not necessarily across runs). That doesn't deny there are multiple comparison concepts people want, it just speaks against a strict weak ordering being one of them. For example, when using binary search on a sorted list to determine membership, people want total ordering. OTOH, when faced with 42 < "42" in isolation, sane Python people want an exception. When faced with "x in sequence_or_mapping", most people want __eq__ but some people want object identity (e.g., it's not always helpful that 3 == 3.0). One size doesn't fit anyone all the time. (*) I have to take that back: people *did* complain when the relative position of None changed. It's an undocumented fact that None compares "less than" non-None objects now (of types that don't force a different outcome), but that wasn't always so, and I clearly recall a few complaints after that changed, from people who apparently deliberately relied on its equally undocumented comparison behavior before.