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

Donald Stufft donald at stufft.io
Fri Nov 21 17:37:49 CET 2014


> On Nov 21, 2014, at 11:31 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
> On 11/21/2014 05:47 AM, Raymond Hettinger wrote:
>> 
>> Also, the proposal breaks a reasonably useful pattern of calling next(subiterator)
>> inside a generator and letting the generator terminate when the data stream  ends.
>> 
>> Here is an example that I have taught for years:
>> 
>>    def [...]
>>        it1 = iter(iterable1)
>>        it2 = iter(iterable2)
>>        while True:
>>            v1 = next(it1)
>>            v2 = next(it2)
>>            yield v1, v2
> 
> Stepping back a little and looking at this code, sans header, let's consider the possible desired behaviors:
> 
>  - have an exact match-up between the two iterators, error otherwise
>  - stop when one is exhausted
>  - pad shorter one to longer one
> 
> Two of those three possible options are going to require dealing with the StopIteration that shouldn't escape -- is the
> trade of keeping one option short and simple worth the pain caused by the error-at-a-distance bugs caused when a
> StopIteration does escape that shouldn't have?
> 

I don’t have an opinion on whether it’s enough of a big deal to actually change
it, but I do find wrapping it with a try: except block and returning easier
to understand. If you showed me the current code unless I really thought about
it I wouldn't think about the fact that the next() calls can cause the
generator to terminate.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



More information about the Python-Dev mailing list