reseting an iterator

norseman norseman at
Thu May 21 19:00:45 EDT 2009

Terry Reedy wrote:
> I will clarify by starting over with current definitions.
> Ob is an iterator iff next(ob) either returns an object or raises 
> StopIteration and continues to raise StopIteration on subsequent calls.
> Ob is an iterable iff iter(ob) raturns an iterator.
> It is intentional that the protocol definitions be minimal, so that they 
> can used as widely as possible.
> As a convenience, the definition of iterators is given a slight 
> complication.  They are defined as a subcategory of iterables, with the 
>  requirement that iter(iterator) be that same iterator.  This means that 
> iterators need the following boilerplate:
>   def __iter__(self): return self
> The extra burden is slight since most iterators are based on builtins or 
> generator functions or expressions, which add the boilerplate 
> automatically.  The convenience is that one may write
> def f(iterable_or_iterator):
>   it = iter(iterable_or_iterator)
>   ...
> instead of
> def f(iterable_or_iterator):
>   if is_iterable(iterable_or_iterator):
>     it = iter(iterable_or_iterator)
>   else:
>     it = iterable_or_iterator
> In particular, the internal function that implements for loops can do 
> the former.
> In other words, a small bit of boilerplate added to iterators, mostly 
> automatically, saves boilerplate in the use of iterators and iterables.
> When the protocols were defined, there was discussion about whether or 
> not to require 'continue to raise StopIteration'.  For instance, an 
> iterator that returns objects derived from external input might not have 
> any new external input now but expect to get some in the future.  It was 
> decided the such iterators should either wait and block the thread or 
> return a 'Not now' indicator such as None.  StopIteration should 
> consistently mean 'Done, over and out' so for loops, for instance, would 
> know to exit.
> The OP proposes that StopIteraton should instead mean 'Done until 

Done unless you put the data pointer back to offset zero

> reset', without defining 'reset'.  Some comments:
> * This would complicate the protocol.
> * There are real use cases, and reiterability is a real issue.  But ...
> * Depending on the meaning, resetting may or may not be possible.
> * When it is possible, it can potentially be done today with a .send() 
> method.
> * Many use cases are easier with a new iterator.  For instance
> for i in iterable: block1()
> for i in iterable: block2()
> is easier to write than
> it = iter(iterable)
> for i in it: block1()
> it.reset()
> for i in it: block2()
> with little relative time saving in the second case, for practical 
> problems, to compensate for the extra boilerplate.

while testing:
   for i in it:

> Terry Jan Reedy

More information about the Python-list mailing list