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 ;-)