[Python-Dev] Re: Re: lists v. tuples

[Tim Peters]

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