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

[Terry Reedy]

On 11/22/2014 5:23 PM, Chris Angelico wrote:
> On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam <ron3200 at gmail.com> wrote:
>>> Making comprehensions work more like generator expressions
>>> would, IMO, imply making the same change to all for loops: having a
>>> StopIteration raised by the body of the loop quietly terminate the
>>> loop.
>>
>>
>> I'm not suggesting making any changes to generator expressions or for loops
>> at all.  They would continue to work like they currently do.
>
> But if you're suggesting making list comps react to StopIteration
> raised by their primary expressions, then to maintain the
> correspondence between a list comp and its expanded form, for loops
> would have to change too. Or should that correspondence be broken, in
> that single-expression loop constructs become semantically different
> from statement loop constructs?

The 2.x correspondence between list comp and for loops was *already 
broken* in 3.0 by moving execution to a new function to prevent name 
binding in comprehension from leaking the way they did in 2.x.  We did 
not change for loops to match.

The following, which is an example of equivalence in 2.7, raises in 3.4 
because 'itertools' is not defined.

def binder(ns, name, ob):
     ns[name] = ob

for mod in ['sys']:
     binder(locals(), mod, __import__(mod))
print(sys)

[binder(locals(), mod, __import__(mod)) for mod in ['itertools']]
print(itertools)

Ceasing to leak *any* local bindings in 3.0 broke equivalence and code 
depending on such bindings.  Ceasing to leak StopIteration would break 
equivalence a bit more, but only a bit, and code dependent on such 
leakage, which I expect is extremely rare.

-- 
Terry Jan Reedy