Re: Odd closure issue for generators

2009-06-08 Thread David Stanek
On Thu, Jun 4, 2009 at 7:42 PM, Scott David Daniels wrote: > Brian Quinlan wrote: >> >> This is from Python built from the py3k branch: >>  >>> c = (lambda : i for i in range(11, 16)) >>  >>> for q in c: >> ...     print(q()) >> ... >> 11 >> 12 >> 13 >> 14 >> 15 >>  >>> # This is expected >>  >>> c

Re: Odd closure issue for generators

2009-06-06 Thread Aahz
In article , Terry Reedy wrote: > >(1) Calling the first and rest methods 'car' and 'cdr' convinces me that >schemers really do not want scheme to be popular, but prefer it to >remain a small cult language. What, you don't get a warm, fuzzy feeling from saying, "Today is the car of the cdr of

Re: Odd closure issue for generators

2009-06-06 Thread Terry Reedy
Michele Simionato wrote: Yes, most functional languages have the concept of streams. You can even define a stream-comprehension that looks like Python generator comprehension but it is an essentially different thing. See for instance http://www.artima.com/weblogs/viewpost.jsp?thread=251159 I

Re: Odd closure issue for generators

2009-06-05 Thread Michele Simionato
On Jun 6, 12:06 am, Terry Reedy wrote: > Brian Quinlan wrote: > > > Sorry, I wasn't as precise as I should have been. > > > If you consider this example: > > ( for x in y) > > > I thought that every time that was evaluated, it would be done in > > a new closure with x bound to the value of x at t

Re: Odd closure issue for generators

2009-06-05 Thread Terry Reedy
Brian Quinlan wrote: Sorry, I wasn't as precise as I should have been. If you consider this example: ( for x in y) I thought that every time that was evaluated, it would be done in a new closure with x bound to the value of x at the time that the closure was created. Instead, a new closur

Re: Odd closure issue for generators

2009-06-05 Thread Brian Quinlan
Ned Deily wrote: In article <[email protected]>, Brian Quinlan wrote: Scott David Daniels wrote: [snipped] When you evaluate a lambda expression, the default args are evaluated, but the expression inside the lambda body is not. When you apply that evaluated lambda expression, the

Re: Odd closure issue for generators

2009-06-05 Thread Aahz
In article , Lawrence D'Oliveiro wrote: >In message ><78180b4c-68b2-4a0c-8594-50fb1ea2f...@c19g2000yqc.googlegroups.com>, Michele >Simionato wrote: >> >> The crux is in the behavior of the for loop: in Python there is a >> single scope and the loop variable is *mutated* at each iteration, >> wh

Re: Odd closure issue for generators

2009-06-05 Thread Michele Simionato
On Jun 5, 11:26 am, "Gabriel Genellina" wrote: > Mmm, the URL ends with: thread, an equals sign, and the number 251156 > If you see =3D -- that's the "=" encoded as quoted-printable... Actually this is the right URL: http://www.artima.com/weblogs/viewpost.jsp?thread=251156 -- http://mail.pytho

Re: Odd closure issue for generators

2009-06-05 Thread Gabriel Genellina
En Fri, 05 Jun 2009 01:49:15 -0300, Aahz escribió: In article <05937a34-5490-4b31-9f07-a319b44dd...@r33g2000yqn.googlegroups.com>, Michele Simionato wrote: Actually, in Scheme one would have to fight to define a list comprehension (more in general loops) working as in Python: the natural d

Re: Odd closure issue for generators

2009-06-05 Thread Lawrence D'Oliveiro
In message <78180b4c-68b2-4a0c-8594-50fb1ea2f...@c19g2000yqc.googlegroups.com>, Michele Simionato wrote: > The crux is in the behavior of the for loop: > in Python there is a single scope and the loop variable is > *mutated* at each iteration, whereas in Scheme (or Haskell or any > other functio

Re: Odd closure issue for generators

2009-06-05 Thread Michele Simionato
On Jun 5, 6:49 am, [email protected] (Aahz) wrote: > In article > <05937a34-5490-4b31-9f07-a319b44dd...@r33g2000yqn.googlegroups.com>, > Michele Simionato   wrote: > > > > >Actually, in Scheme one would have to fight to define > >a list comprehension (more in general loops) working as > >in Pyt

Re: Odd closure issue for generators

2009-06-05 Thread Michele Simionato
On Jun 5, 6:49 am, [email protected] (Aahz) wrote: > In article > <05937a34-5490-4b31-9f07-a319b44dd...@r33g2000yqn.googlegroups.com>, > Michele Simionato   wrote: > > > > >Actually, in Scheme one would have to fight to define > >a list comprehension (more in general loops) working as > >in Pyt

Re: Odd closure issue for generators

2009-06-04 Thread Lawrence D'Oliveiro
In message , Brian Quinlan wrote: >>>> c = (lambda : i for i in range(11, 16)) >>>> d = list(c) >>>> for q in d: >...print(q()) >... >15 >15 >15 >15 >15 Try >>> c = ((lambda i : lambda : i)(i) for i in range(11, 16)) >>> d = list(c) >>

Re: Odd closure issue for generators

2009-06-04 Thread Ned Deily
In article <[email protected]>, Brian Quinlan wrote: > Scott David Daniels wrote: > [snipped] > > When you evaluate a lambda expression, the default args are evaluated, > > but the expression inside the lambda body is not. When you apply that > > evaluated lambda expression, the expr

Re: Odd closure issue for generators

2009-06-04 Thread Aahz
In article <05937a34-5490-4b31-9f07-a319b44dd...@r33g2000yqn.googlegroups.com>, Michele Simionato wrote: > >Actually, in Scheme one would have to fight to define >a list comprehension (more in general loops) working as >in Python: the natural definition works as the OP wants. See >http://www.arti

Re: Odd closure issue for generators

2009-06-04 Thread Dave Angel
Carl Banks wrote: The way to handle the issue you are seeing is to create a new scope with a variable the remains at the value you want to close upon: create_const_function(value): def func(): return value c =create_const_function(i) for i in range(11, 16)) Or you can do it the sl

Re: Odd closure issue for generators

2009-06-04 Thread Brian Quinlan
Scott David Daniels wrote: [snipped] When you evaluate a lambda expression, the default args are evaluated, but the expression inside the lambda body is not. When you apply that evaluated lambda expression, the expression inside the lambda body is is evaluated and returned. But that's not real

Re: Odd closure issue for generators

2009-06-04 Thread Michele Simionato
On Jun 5, 1:18 am, Carl Banks wrote: > It's really the only sane way to handle it, odd though it may seem in > this narrow case.  In Python nested functions have to be able to > reference the current value of a variable because of use cases like > this: > > def func(): >     def printx(): >      

Re: Odd closure issue for generators

2009-06-04 Thread Brian Quinlan
Gabriel Genellina wrote: En Thu, 04 Jun 2009 18:40:07 -0300, Brian Quinlan escribió: This is from Python built from the py3k branch: It's not new; same thing happens with 2.x A closure captures (part of) the enclosing namespace, so names are resolved in that environment even after the enc

Re: Odd closure issue for generators

2009-06-04 Thread Scott David Daniels
Brian Quinlan wrote: This is from Python built from the py3k branch: >>> c = (lambda : i for i in range(11, 16)) >>> for q in c: ... print(q()) ... 11 12 13 14 15 >>> # This is expected >>> c = (lambda : i for i in range(11, 16)) >>> d = list(c) >>> for q in d: ... print(q()) ... 15

Re: Odd closure issue for generators

2009-06-04 Thread Carl Banks
On Jun 4, 2:40 pm, Brian Quinlan wrote: > This is from Python built from the py3k branch: >  >>> c = (lambda : i for i in range(11, 16)) >  >>> for q in c: > ...     print(q()) > ... > 11 > 12 > 13 > 14 > 15 >  >>> # This is expected >  >>> c = (lambda : i for i in range(11, 16)) >  >>> d = list(c

Re: Odd closure issue for generators

2009-06-04 Thread Gabriel Genellina
En Thu, 04 Jun 2009 18:40:07 -0300, Brian Quinlan escribió: This is from Python built from the py3k branch: It's not new; same thing happens with 2.x A closure captures (part of) the enclosing namespace, so names are resolved in that environment even after the enclosing block has finishe