Guido van Rossum
guido at python.org
Tue Oct 14 10:46:16 EDT 2003
> I have no opinion about the importance, but I do have a use case that
> differs from Tim's.
> The other week I found myself sorting a list of dictionary keys by an
> arbitrary attribute of the dict values. The sort needed to be stable, in
> the sense that for attributes that contained equal values, the previous
> sort order was to be maintained. The dict values themselves weren't
> meaningfully sortable. What I did (had to do, given the requirements) is
> almost exactly what Tim proposes (I included the indices in the sort),
> so having that functionality built into list.sort() would have been
> helpful for me. Not having that functionality would mean I'd either not
> use the decorator sort feature (ie. do what I do now) or go through
> hoops and make the decorator generate the indices. The latter approach
> doesn't sound very appealing to me.
Hm. I wonder this could be solved by yet another keyword argument
(maybe "stable"?) controlling whether to add the index to the key a la
I note that there are many different uses of sort. Many common uses
only sort small lists, where performance doesn't matter much; I often
use an inefficient cmp function without worrying about performance in
such cases. But there are also uses that really test the extremes of
Python's performance, and it's a tribute to Tim that his sort code
stands up so well in that case. I think it's inevitable that the
default options aren't necessarily best for *all* use cases.
I'm not sure whether the defaults should cater to the extreme
performance cases or to the smaller cases; I expect that the latter
are more common, and people who are sorting truly huge lists should
read the manual if they care about performance. But that's just me.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev