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

[Terry Reedy]

Nick Coghlan wrote:
> 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.

The latter could be over-spec'ed because people are used to that being 
the choice, or because 'sequence' is being used as a synonym for 
'reiterable' even though it implies more than is needed.

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

Which may or may not be needed.

def pairs(finite_reiterable)
   for i in finite_reiterable:
     for j in finite)reiterable:
       return (i,j)

is a simple function for which 'finite_reiterable' is exactly the 
appropriate spec.  The issue is whether it is best to wrap it internally 
(inline) with a generic list(it) or to let the caller special-case 
iterator constructors.

> 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).

Yes.

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

Which I mentioned in my original post. I specificlly considered how to 
make iterator constructors, more common in 3.x, reiterable *without* 
storing everything in memory. Avoiding such storage is why map, filter, 
range, for example, were changed. So it hardly seems like an oddball aim.

> 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()

As I understand, everything goes into the tee and everything comes out 
in order, so I don't understand what you mean keeping some value.

> In other words, this strikes as a fairly complicated solution to a
> rather limited problem.

I believe someone else though it was too simple for the stdlib ;-)
The solution is a variation of functools.partial.

I would certainly look for more concrete use cases, perhaps in the 
stdlib, before seriously proposing it for inclusion.

Terry Jan Reedy