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:
yes, this was a reply to your post
Yes, that would keep iterator classes and generator functions consistent, which would be a good thing.
I think the main goal was to have a consistent interface that is easy to debug and deals with StopIteration bubbling up - hence such Exception from other scopes should convert to RuntimeError when crossing the iterator interface boundary originating from other scopes.
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.
You'd Keep StopIteration in the protocol, but only allow it in the local scope.
-Alexander