Guido van Rossum wrote: > After reading this exchange, I'm not sure I agree with Tim about the > importance of avoiding to compare the full records. Certainly the > *cost* of that comparison doesn't bother me: I expect it's usually > going to be a tuple or list of simple types like ints and strings, and > comparing those is pretty efficient. 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. Just
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