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

[Chris Angelico]

On Tue, Nov 25, 2014 at 3:38 AM, Chris Barker <chris.barker at noaa.gov> wrote:
> On Fri, Nov 21, 2014 at 4:56 PM, Alexander Heger <python at 2sn.net> wrote:
>>
>> Maybe a way to obtain equivalency to the generator functions in this
>> case is to "break" this example for the iterator object as well, in
>> that StopIteration has to be raised in the frame of the generator
>> object; if it raised in a different context, e.g., a function called
>> by __next__, that StopIteration should also be converted to a
>> RuntimeError similar to what is proposed in the PEP for the generator
>> functions.  Maybe this is not what Chris intends to happen, but it
>> would make things consistent.
>
>
> I"mn not sure which Chris you are refering to, but for my part, yes and no:

That's one of the perils of geeky communities - there'll often be
multiple people named Chris. I have a brother named Michael who's a
rail enthusiast, and that world has the same issue with his name - he
was once in a car with three other people named Michael.

> Yes, that would keep iterator classes and generator functions consistent,
> which would be a good thing.
>
> No: I don't think we should do that -- StopIteration is part of the iterator
> protocol -- generators are another way to write something that complies with
> the iterator protocol -- generators should handle StopIteration the same way
> that iterator classes do.

I've done my "explain it twice, then shut up" on this subject, so I'll
just point you to the list archive, where it's been stated clearly
that generators are like __iter__, not like __next__. Please, could
you respond to previously-given explanations, rather than simply
restating that generators should be like __next__? I'd like to move
forward with that discussion, rather than reiterating the same points.

ChrisA