Tim Peters wrote:
> [Kevin J. Butler]
> > I think just about everyone gets tripped up by the "sort returns None"
> > behavior, and though one (e.g., BDFL) can declare that it is a less
> > significant stumble than not realizing the list is sorted in place, it
> > is a _continuing_ inconvenience, with virtually every call to [].sort,
> > even for Python experts (like Barry, not me).
>
> People would get in worse (subtler) trouble if it did return self. The
> trouble they get from it returning None is all of shallow, immediate, easily
> fixed, and 100% consistent with other builtin container mutating methods
> (dict.update, dict.clear, list.remove, list.append, list.extend,
> list.insert, list.reverse).
>
> That said, since we're having a fire sale on optional sort arguments in 2.4,
> I wouldn't oppose an optional Boolean argument you could explicit set to
> have x.sort() return x. For example,
>
> >>> [1, 2, 3].sort(happy_guido=False)
> [1, 2, 3]
> >>>
If anything at all, i'd suggest a std-module which contains e.g.
'sort', 'reverse' and 'extend' functions which always return
a new list, so that you could write:
for i in reverse(somelist):
...
which wouldn't modify the list but return a new one. I don't have
a name for such a module, but i have once written a "oneliner"
to implement the above methods (working on tuples, strings, lists):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/119596
(sorry this was in my early days :-)
have fun,
holger
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