list.sort, was Re: [Python-Dev] decorate-sort-undecorate

Raymond Hettinger python at
Fri Oct 17 17:45:26 EDT 2003

[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() ?

> > You can do reverse with [::-1] now.

[Holger Krekel]
> sure, but it's a bit unintuitive and i mentioned not only reverse :-)
> Actually i think that 'reverse', 'sort' and 'extend' algorithms
> could nicely be put into the new itertools module.
> There it's obvious that they wouldn't mutate objects.  And these
> algorithms
> (especially extend and reverse) would be very efficient as iterators
> because
> they wouldn't create temporary lists/tuples.

To be considered as a possible itertool, an ideal candidate should:

* work well in combination with other itertools
* be a fundamental building block
* accept all iterables as inputs
* return only an iterator as an output
* run lazily so as not to force the inputs to run to completion
  unless externally requested by list() or some such.
* consume constant memory (this rule was bent for itertools.cycle(),
  but should be followed as much as possible).
* run finitely if some of the inputs are finite (itertools.repeat(),
  count() and cycle() are the only intentionally infinite tools)

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.

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

Raymond Hettinger

More information about the Python-Dev mailing list