Tim Peters <t...@python.org> added the comment:
Ah, so you're proposing a hack that would catch some, but not all, cases where a total ordering doesn't exist. Why? The issue tracker isn't a suitable place to discuss it regardless, so if you want to pursue it I'd suggest taking it to python-ideas. If you do, some points to think about in advance: - As above, it only catches some cases. For example, given list [a, b], where a < b and b < a, no total ordering exists but the hack won't detect anything amiss. - As has been said twice already, list.sort() promises to use only "<". This isn't disposable. User-written classes _rely_ on it, which was the point: for instances to participate in sorting, the class only needs to define __lt__ (and, although it's not currently documented, they can also participate in the `bisect` and `heapq` module facilities, which also restrict themselves to "<" compares). - Assuming "a < b" is false about half the time, the hack would require sorting to do about 50% more comparisons. That's a huge expense. All in all, I've spent at least a year of my life minimizing the number of compares Python's sort needs to do, and that would more than wipe out all the progress I've made since 1991 ;-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36095> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
