[Python-Dev] Re: anonymous blocks

Steven Bethard steven.bethard at gmail.com
Thu Apr 28 06:59:27 CEST 2005

Phillip J. Eby wrote:
> At 05:19 PM 4/27/05 -0700, Guido van Rossum wrote:
> >I'm not convinced of that, especially since all *generators* will
> >automatically be usable as templates, whether or not they were
> >intended as such. And why *shouldn't* you be allowed to use a block
> >for looping, if you like the exit behavior (guaranteeing that the
> >iterator is exhausted when you leave the block in any way)?
> It doesn't guarantee that, does it?  (Re-reads PEP.)  Aha, for *generators*
> it does, because it says passing StopIteration in, stops execution of the
> generator.  But it doesn't say anything about whether iterators in general
> are allowed to be resumed afterward, just that they should not yield a
> value in response to the __next__, IIUC.  As currently written, it sounds
> like existing non-generator iterators would not be forced to an exhausted
> state.

I wonder if something can be done like what was done for (dare I say
it?) "old-style" iterators:

"The intention of the protocol is that once an iterator's next()
method raises StopIteration, it will continue to do so on subsequent
calls. Implementations that do not obey this property are deemed
broken. (This constraint was added in Python 2.3; in Python 2.2,
various iterators are broken according to this rule.)"[1]

This would mean that if next(itr, ...) raised StopIteration, then
next(itr, ...) should continue to raise StopIteration on subsequent
calls.  I don't know how this is done in the current implementation. 
Would it be hard to do so for the proposed block-statements?

If nothing else, we might at least clearly document what well-behaved
iterators should do...


[1] http://docs.python.org/lib/typeiter.html
You can wordify anything if you just verb it.
        --- Bucky Katt, Get Fuzzy

More information about the Python-Dev mailing list