On Fri, Nov 21, 2014 at 2:29 PM, Guido van Rossum email@example.com 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.