At 15:14 21.10.2003 -0700, Guido van Rossum wrote:
[name withheld]
The implementation could synthesize a generator function abusing default arguments to give the generator's frame locals with the same names.
[Guido]
Yes, I think that could work -- I see no way that something invoked by the generator expression could possibly modify a variable binding in the surrounding scope.
[Samuele]
so this, if I understand:
def h(): y = 0 l = [1,2] it = (x+y for x in l) y = 1 for v in it: print v
will print 1,2 and not 2,3
unlike:
def h(): y = 0 l = [1,2] def gen(S): for x in S: yield x+y it = gen(l) y = 1 for v in it: print v
Argh. Of course.
No, I think it should use the actual value of y, just like a nested function.
Never mind that idea then.
this is a bit OT and too late, but given that our closed over variables are read-only, I'm wondering whether, having a 2nd chance, using cells and following mutations in the enclosing scopes is really worth it, we kind of mimic Scheme and relatives but there outer scope variables are also rebindable. Maybe copying semantics not using cells for our closures would not be too insane, and people would not be burnt by trying things like this: for msg in msgs: def onClick(e): print msg panel.append(Button(msg,onClick=onClick)) which obviously doesn't do what one could expect today. OTOH as for general mutability, using a mutable object (list,...) would allow for mutability when one really need it (rarely).