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