[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
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