Tim Peters <t...@python.org> added the comment:
> Elliot shortly after retrated from the approach, saying he
> rewrote unsafe_tuple_compare to move the less-than after
> the equality testing, to make sure it's 100% consistent".
I remember at the time having no idea what he meant by that comment - and I
still have no idea ;-)
> The proposed method would change comparisons of *the same* tuples.
> You'd for example no longer have
> "sorted(tuples) == [min(tuples), max(tuples)]"
> for a list of two tuples.
Since very little is defined about the result of sorted() in the absence of a
total ordering (just that it's _some_ permutation of the original), that's not
surprising. It's already the case anyway (using the released 3.10.0):
>>> ts = [(float("nan"), 1), (float("nan"), 1.0)]
>>> sorted(ts) == [min(ts), max(ts)]
False
> I recently saw a case where despite the "only <" promise, sorting
> caused an "x > y" comparison (because "y < x" wasn't implemented).
Sorting itself never asks for __gt__, only __lt__. What the _rest_ of the
language does to implement __lt__ is out of sorting's control. For example,
tuple.__lt__ and list.__lt__ go on to invoke __eq__ on contained elements. A
more general subsystem in the language falls back on x.__gt__(y) if y.__lt__(x)
isn't implemented. Sorting has no control over any of that.
> tupsort.py does "range(2", should be "range(1" I think)
Good catch - thanks! Repaired now :-)
----------
Added file: https://bugs.python.org/file50373/tupsort.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue45530>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
