list.sort, was Re: [Python-Dev] decorate-sort-undecorate
Holger Krekel
pyth at devel.trillke.net
Fri Oct 17 18:27:42 EDT 2003
Raymond Hettinger wrote:
> [Gustavo Niemeyer wrote]
> > > > 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
> > > > a new list, so that you could write:
> > > >
> > > > for i in reverse(somelist):
> > > > ...
>
> sort: This is being addressed by the proposed list.copysort() method
> reverse: This is being addressed by PEP-0322. When I get a chance,
> the PEP will be revised to propose a builtin instead of
> various methods attached to specific sequence objects.
> extend: How would this differ from itertools.chain() ?
pointing someone to these three different specific (somewhat limited)
solutions for the "i want reverse/sort/extend/... not to work inplace but
on-the-fly" requirement seems tedious.
> There is no chance for isort(). Once you've sorted the whole list,
> there is no advantage to returning an iterator instead of a list.
Providing a uniform concept counts as an advantage IMO. Agreed, performance
wise there probably is no advantage with the current sorting-algorithm.
> The problem with ireverse() is that it only works with objects that
> support __getitem__() and len(). That pretty much precludes
> generators, user defined class based iterators, and the outputs
> from other itertools. So, while it may make a great builtin (which
> is what PEP-322 is going to propose), it doesn't fit in with other
> itertools.
I wouldn't mind if reverse would - as a fallback - suck all elements and
then spit them out in reverse order. After all, you sometimes want to
process yielded values from an iterator in reverse order and there is
not much else you can do than to exhaust the iterator.
cheers,
holger
More information about the Python-Dev
mailing list