>> Would it make sense to provide a default ordering whenever the types are >> the same? > > This doesn't work when they are not the same :-) _ ~ @ @ \_/ > Instead, you could make the decorating a bit more sophisticated: > > decorated = [(key, id(value), value) for key, value in blah(values)] > > or even: > > decorated = [(key, n, value) for n, key, value in enumerate(blah(values))] I already do something along those lines in heapq.nsmallest() and nlargest() to preserve sort stability. The real issue isn't how to fix one particular module. The problem is that a basic python pattern is now broken in a way that may not readily surface during testing. I'm wondering if there is something we can do to mitigate the issue in a general way. It bites that the venerable technique of tuple sorting has lost some of its mojo. This may be an unintended consequence of eliminating default comparisons. Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4