RetroSearch Browse

Tue Oct 21 18:43:49 EDT 2003 · http://mail.python.org/pipermail/python-dev/2003-October/039212.html

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).

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2003-October/039212.html below:

[Python-Dev] accumulator display syntax