On Tue, Nov 25, 2014 at 3:38 AM, Chris Barker chris.barker@noaa.gov wrote:
On Fri, Nov 21, 2014 at 4:56 PM, Alexander Heger python@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