> On Wed, Oct 15, 2003, Guido van Rossum wrote: > > That sounds like an extremely roundabout way of doing it; *if* there > > had to be a way to request a stable sort, I'd say that specifying a > > 'stable' keyword would be the way to do it. But I think that's > > unnecessary. > > > > Given that the Jython folks had Tim's sort algorithm translated into > > Java in half a day, I don't see why we can't require all > > implementations to have a stable sort. It's not like you can gain > > significant speed over Timsort. [Aahz] > But in the discussion leading up to adopting Timsort, you (or Tim, same > difference ;-) explicitly said that you didn't want to make any doc > guarantees about stability in case the sort algorithm changed in the > future. That was before Timsort had proven to be such a tremendous success. > I don't have an opinion about whether we should keep our > options open, but I do think there should be a clearly explicit decision > rather than suddenly assuming that we're going to require Python's core > sort to be stable. OK, I pronounce on this: Python's list.sort() shall be stable. --Guido van Rossum (home page: http://www.python.org/~guido/)
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