[Python-Dev] accumulator display syntax
Samuele Pedroni
pedronis at bluewin.ch
Tue Oct 21 18:43:49 EDT 2003
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).
More information about the Python-Dev
mailing list