Python's simplicity philosophy

[Paul Rubin]

"Terry Reedy" <tjreedy at udel.edu> writes:
> Which is why Guido long resisted making such a guarantee, in spite of
> many requests.  (The previous list.sort was not stable.)  However,
> timsort is stable, tested for about a year, and so fast for lists both
> random and with various types of order, and so close to optimal in
> terms of number of comparisons, that Guido was willing to 'annoint' it
> as list.sort for the indefinite future.  If there were a generally
> useful non-stable sort discovered proposed in the future, is could be
> added under a different name.

I think that decision is a little too CPython-centric.  Some other
Python implementation (maybe even Jython) might like to implement the
list.sort method by calling some other sort routine (like the one
already in the library for that language) rather than by porting
timsort, even if timsort is better.  Also, someone might want to
implement an indexable class that isn't a list (maybe it's a disk file
or something) and want to give it a sort method that cannot work by
sucking the keys into memory and calling timsort (maybe there are too
many keys to fit in memory, so external methods must be used).  It may
turn out to work best to use some nonstable sorting method, but then
the behavior will be inconsistent with list.sort and that makes more
cruft that the application programmer has to remember.  

Most sorting applications don't care about stability.  I think if a
new sorting method is going to get added so there's separate methods
for guaranteed-stable and possibly-nonstable sorting, it's best to let
the new method be the stable one (maybe list.ssort) and leave the
existing one alone.

Of course then you want variants that return self instead of None, so
you have list.sort, list.ssort, list.nsort, and list.nssort.  It gets
out of hand.  

Maybe the best way to do this kind of thing is with keyword arguments
rather than new methods.