[Python-Dev] Re: Reiterability

[Alex Martelli]

On Monday 20 October 2003 03:04 am, Guido van Rossum wrote:
> FWIW, I partially withdraw my observation that reiterability is a
> special case of cloneability.  It is true that if you have
> cloneability you have reiterability.  But I hadn't realized that
> reiterability is sometimes easier than cloneability!

Hmmm, I thought I had shown a simple wrapper (holding a callable and args for 
it, as you show later) that implied how to wrap, at creation time, iterators 
built by iter(sequence) or by generators for reiterability (but not for 
cloneability).  So, sure, cloneability is more general (you can use it to 
implement reiterability, but not VV) and harder to implement; reiterability 
IS "a special case" and thus it's less general but easier to implement.

> But this doesn't make me any more comfortable with the idea of adding
> reiterability as an iterator feature (even optional).

Sure.  "Relatively easy to implement" doesn't mean "should be in the
language".  Ease of learning, breadth and appropriateness of use, risk
of misuse, ease of substitution if not in the language -- there are so
many considerations!


> With reiter() it becomes hard to explain what the input requirements
> are for the function to work correctly; effectively, it would require
> a "virginal" (== has never been used :-) reiterable iterator.  So we

Yes, very good point -- and possibly the explanation of why I never
met a use case for reiterability as such.  It's unlikely I want "an
iterator that may already be partly consumed but I can restart
from an unknown-to-me ``previous'' point in its lifetime" -- then
I probably just want an iterable, just as you say.

> might as well require a container!  If you don't have a container but
> you have a description of a series, Alex's Reiterable can easily fix
> this:
>
>   class Reiterable:
>       def __init__(self, func, *args):
>           self.func, self.args = func, args
>       def __iter__(self):
>           return self.func(*self.args)
>
> This should be called with e.g. a generator function and an argument
> list for it.

Yes, or the function that needs a callable + args anyway might require
the callable and the args as its own arguments instead of wanting them
packaged up as an iterable (an iterable's probably better if the typical
use case is passing e.g. a list, though -- asking for the "iterator factory"
callable might help when the typical use case is passing a generator).

Yet another nail in the coffin of "reiterable as a concept in the language",
methinks.


Alex