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

Scott David Daniels Scott.Daniels at Acm.Org
Fri Oct 17 18:30:44 EDT 2003


[Raymond Hettinger]
> 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.
Actually, some case can be made:
loading prepares a heap, iterating extracts the heap top.

sit = isort(someiter)
sit.next()    is the winner.
Then
sit.next()    is second-place (or a tie with the winner).
q = sit.next()
[q] + takewhile(lambda x: x==q, sit)
               is all who tied with the runner-up.


Which isn't to say I think it fits.  But there are reasons to
get everything and then dole out parts.

-Scott David Daniels
Scott.Daniels at Acm.Org





More information about the Python-Dev mailing list