[Python-ideas] PEP 479: Change StopIteration handling inside generators

Chris Barker chris.barker at noaa.gov
Sat Nov 22 00:06:10 CET 2014


On Fri, Nov 21, 2014 at 2:29 PM, Guido van Rossum <guido at python.org> wrote:

> Honestly, I'm a bit lost -- but my point is this -- generators and
>> iterators should behave as much the same as possible.
>>
>
> I'm sorry you see it that way; we must have done a terrible job explaining
> this in the past. :-(
>

well, others have found examples in old docs that mingle StopIteration and
generators...so I guess so, but I'm not sure I'm that misinformed. It still
seems to me that there are two ways to write the same thing.

The behavior for the *consumer* of the iteration is unchanged
>

got it -- the issue at hand is what happens to a StopIteration that is
raised by something the generator calls.

I think the point of this PEP is that the author og a generator function is
thinking about using "yield" to provide the next value, and return
(explicit or implicit) to stop the generation of objects. That return is
raise a StopIteration, but the author isn't thinking about it.

So why would they want to think about having to trap StopIteration when
calling other functions.

While the author of a iterator class is thinking about the __next__ method
and raising a StopIteration to terminate. So s/he would naturally think
about trapping StopIteration when calling functions?

I suppose that makes some sense, but to me it seems like a generator
function is a different syntax for creating what is essentially the same
thing -- why shouldn't it have the same behavior?

and of you are writing a generator, presumably you know how it's going to
get use -- i.e. by somethign that expects a StopIteration -- it's not like
you're ignorant of the whole idea.

Consider this far fetched situation:

Either a iterator class or a generator function could take a function
object to call to do part of its work. If that function happened to raise a
StopIteration -- now the user would have to know which type of object they
were workign with, so they would know how to handle the termination of the
iter/gener-artion

OK -- far more far fetched than the proceeding example of confusion, but
the point is this:

AFAIU, the current distinction between generators and iterators is how they
are written -- i.e. syntax, essentially. But this PEP would change the
behavior of generators in some small way, creating a distinction that
doesn't currently exist.

So, again, the PEP does not change anything about iterators, and generators
> will continue to follow the iterator protocol. The change is only for
> generator authors
>

I guess this is where I'm not sure -- it seems to me that the behavior of
generators is being change, not the syntax -- so while mostly of concern to
generator authors, it is, in fact, a chance in behavior that can be seen by
the consumer of (maybe only an oddly designed) generator. In practice, that
difference may only matter to folks using that particular hack in generator
expression, but it is indeed a change.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141121/604eb301/attachment-0001.html>


More information about the Python-ideas mailing list