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
I think this is a good point.
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.