[Just] > 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 Tim's recipe. 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/)
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