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