[Python-ideas] Aid reiteration with new class: gfic

[Nick Coghlan]

Paul Moore wrote:
> 2009/6/20 Terry Reedy <tjreedy at 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 at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------