Paul Moore wrote:
2009/6/20 Terry Reedy <tjreedy@udel.edu>:
I am looking at the issue from the caller's viewpoint. I have an iterator constructor and I want to use an existing function that requires a re-iterable.
OK. But how many functions require a re-iterable? It doesn't seem to me to be a common requirement.
And if they did, how often would it be a problem to construct a list?
I see your point, but I can't imagine it's a common need. But your experience may differ.
Mostly avoiding this discussion, but I think the use cases are even narrower than that. 1. I've never seen a function parameter spec'ed as iterable vs reiterable. It's always iterable vs sequence. 2. "Sequence" implies a lot more than "reiterable" does: it also implies length, containment test support, random access. So any idea focused solely on reiterability misses out on those extra features. 3. Terry's idea also assumes a deterministic data source. An iterator with a random element or a data feed from the real world can't be used with it (because the original sequence can't be reproduced without saving it). 4. The only reliable way to make an arbitrary iterator reiterable is to cache the results in memory, but we already have a way to do that (i.e. store it in a list or tuple) 5. For iterator based cases where only *some* of the values need to be kept around rather than all of them, then the algorithm implementation should be redesigned so it can make effective use of itertools.tee() In other words, this strikes as a fairly complicated solution to a rather limited problem. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------