Python's simplicity philosophy

[Paul Rubin]

"Andrew Dalke" <adalke at mindspring.com> writes:
> The 'against' side says, as you do, that having list.sort required
> to be stable now places an extra barrier to anyone else who
> implements a list-alike sort, because that sort should now also
> be stable.

It's also a barrier to anyone who implements list sort, not just
listalike sort.  Of course that doesn't affect CPython or Jython
users, who already have a built-in stable list sort.  But what about
PyPy or maybe someone trying to reimplement Python from scratch in C?

> What mollifies the latter view is that some user-defined sorts
> won't have ties, so there will never be a problem.  

I'm not a sorting whiz but my feeling is that if an application needs
sort to be stable, that's already a sign that something isn't really
right about it.  Sorting is supposed to mean turning an unordered
permutation into an ordered one.  So if list.sort gives you a useable
answer (i.e. one that satisfies your application's needs), then
randomizing the list and then sorting it should also give you a
useable answer.  The way to do that is make your comparison function
look at every part of the record that you care about, not just select
some single field and count on stability to take care of the rest.  If
at all possible, design the comparison function so that there are
never any ties.  To do otherwise has in my experience been a source of
bugs that don't become evident til much later.