Hrvoje Niksic wrote:
Common Lisp behaves similar to Python in this
regard:
* (loop for i from 0 to 2 collect (lambda () i))
I wouldn't call the CL loop macro the equivalent of
a for-loop. It's more like a while-loop.
The Lisp equivalent of a Python for-loop would be
to use one of the mapping
On Oct 3, 3:47 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> greg wrote:
> > jhermann wrote:
>
> >> I didn't see this mentioned in the thread yet: the double-lambda is
> >> unnecessary (and a hack).
>
> > Well, the alternative -- abusing default argument values --
> > is seen by many to be a hack as
Hrvoje Niksic wrote:
greg <[EMAIL PROTECTED]> writes:
I don't think it has anything to do with variable leaking out of the
loop. Common Lisp doesn't leak the loop variable, and it behaves the
same. It is more a result of the different views of what iteration
is. Common Lisp and Python defin
greg wrote:
jhermann wrote:
I didn't see this mentioned in the thread yet: the double-lambda is
unnecessary (and a hack).
Well, the alternative -- abusing default argument values --
is seen by many to be a hack as well, possibly a worse one.
I disagree. It is one way to evaluate an express
On Oct 3, 3:44 am, greg <[EMAIL PROTECTED]> wrote:
> jhermann wrote:
> > I didn't see this mentioned in the thread yet: the double-lambda is
> > unnecessary (and a hack).
>
> Well, the alternative -- abusing default argument values --
> is seen by many to be a hack as well, possibly a worse one.
>
greg <[EMAIL PROTECTED]> writes:
> The root of the problem actually has nothing to do with lambdas or
> static vs. non-static scoping. It's the fact that Python's for-loop
> doesn't create a new environment for the loop variable each time
> around, but re-uses a slot in the containing environment.
On Oct 3, 10:44 am, greg <[EMAIL PROTECTED]> wrote:
> So if anything were to be done to the language to
> fix this, it really should be focused on fixing the
> semantics of the for-loop. Unfortunately, the
> fact that the loop variable leaks out of the scope
> of the loop is regarded as a feature,
jhermann wrote:
I didn't see this mentioned in the thread yet: the double-lambda is
unnecessary (and a hack).
Well, the alternative -- abusing default argument values --
is seen by many to be a hack as well, possibly a worse one.
It doesn't work in general, e.g. it fails if the function
needs
On Oct 1, 5:43 am, jhermann <[EMAIL PROTECTED]> wrote:
> I didn't see this mentioned in the thread yet: the double-lambda is
> unnecessary (and a hack). What you should do when you need early
> binding is... early binding. ;)
>
> Namely:
>
> f = [lambda n=n: n for n in range(10)]
> print f[0]()
> p
On 1 Okt, 12:43, jhermann <[EMAIL PROTECTED]> wrote:
>
> f = [lambda n=n: n for n in range(10)]
> print f[0]()
> print f[1]()
>
> Note the "n=n", this prints 0 and 1 instead of 9/9.
Yes, Terry mentioned this in his response to my first message. Not
with lambdas, however, but he did state that he d
I didn't see this mentioned in the thread yet: the double-lambda is
unnecessary (and a hack). What you should do when you need early
binding is... early binding. ;)
Namely:
f = [lambda n=n: n for n in range(10)]
print f[0]()
print f[1]()
Note the "n=n", this prints 0 and 1 instead of 9/9.
--
htt
On 29 Sep, 19:26, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> Please: Python does not have 'lambda functions'. Def statements and
> lambda expressions both define instances of the function class. So this
> amounts to saying "functions are subject to the same caveats as functions."
I myself am awa
On Sep 29, 9:14 am, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 29 Sep, 05:56, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>
>
> > As I understand it, partly from postings here years ago...
>
> > Lexical: The namespace scope of 'n' in inner is determined by where
> > inner is located in the code -- wh
Paul Boddie wrote:
On 29 Sep, 05:56, Terry Reedy <[EMAIL PROTECTED]> wrote:
...
Dynamic: The namespace scope of 'n' in inner, how it is looked up, is
determined by where inner is called from. This is what you seemed to be
suggesting -- look up 'n' based on the scope it is *used* in.
...
A so
On Sep 28, 6:43 am, "Aaron \"Castironpi\" Brady"
<[EMAIL PROTECTED]> wrote:
> Hello all,
>
> To me, this is a somewhat unintuitive behavior. I want to discuss the
> parts of it I don't understand.
>
> >>> f= [ None ]* 10
> >>> for n in range( 10 ):
>
> ... f[ n ]= lambda: n
> ...>>> f[0]()
> 9
On 29 Sep, 05:56, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> As I understand it, partly from postings here years ago...
>
> Lexical: The namespace scope of 'n' in inner is determined by where
> inner is located in the code -- where is is compiled. This is Python
> (and nearly all modern languages)
In message
<[EMAIL PROTECTED]>,
Aaron "Castironpi" Brady wrote:
> [Wikipedia] says:
> "dynamic scoping can be dangerous and almost no modern languages use
> it", but it sounded like that was what closures use.
Closures will use whatever the language says they use. LISP used dynamic
binding, but t
Aaron "Castironpi" Brady wrote:
On Sep 28, 4:47 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
Aaron "Castironpi" Brady wrote:
inner = lambda: n
when inner is actually compiled outside of outer, it is no longer a
closure over outer's 'n' and 'n' will be looked for in globals instead.
outer = l
On Sep 28, 4:47 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Aaron "Castironpi" Brady wrote:
> > On Sep 28, 2:52 am, Steven D'Aprano <[EMAIL PROTECTED]
> >> As for why the complicated version works, it may be clearer if you expand
> >> it from a one-liner:
>
> >> # expand: f[ n ]= (lambda n: ( lamb
On Sun, 28 Sep 2008 17:47:44 -0400, Terry Reedy wrote:
> Aaron "Castironpi" Brady wrote:
>> On Sep 28, 2:52 am, Steven D'Aprano <[EMAIL PROTECTED]
>
>>> As for why the complicated version works, it may be clearer if you
>>> expand it from a one-liner:
>>>
>>> # expand: f[ n ]= (lambda n: ( lambda
Aaron "Castironpi" Brady wrote:
On Sep 28, 2:52 am, Steven D'Aprano <[EMAIL PROTECTED]
As for why the complicated version works, it may be clearer if you expand
it from a one-liner:
# expand: f[ n ]= (lambda n: ( lambda: n ) )( n )
inner = lambda: n
outer = lambda n: inner
f[n] = outer(n)
o
On Sep 28, 2:52 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 27 Sep 2008 21:43:15 -0700, Aaron \"Castironpi\" Brady wrote:
> > Hello all,
>
> > To me, this is a somewhat unintuitive behavior. I want to discuss the
> > parts of it I don't understand.
>
> f= [ Non
On Sat, 27 Sep 2008 21:43:15 -0700, Aaron \"Castironpi\" Brady wrote:
> Hello all,
>
> To me, this is a somewhat unintuitive behavior. I want to discuss the
> parts of it I don't understand.
>
f= [ None ]* 10
for n in range( 10 ):
> ... f[ n ]= lambda: n
> ...
f[0]()
> 9
Aaron "Castironpi" Brady wrote:
Hello all,
To me, this is a somewhat unintuitive behavior. I want to discuss the
parts of it I don't understand.
f= [ None ]* 10
for n in range( 10 ):
... f[ n ]= lambda: n
This is equivalent to
for n in range(10):
def g(): return n
f[n] = g
which
On Sep 28, 1:14 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Sat, 27 Sep 2008 21:43:15 -0700, Aaron \"Castironpi\" Brady wrote:
> > To me, this is a somewhat unintuitive behavior. I want to discuss the
> > parts of it I don't understand.
>
> f= [ None ]* 10
> for n in ran
On Sat, 27 Sep 2008 21:43:15 -0700, Aaron \"Castironpi\" Brady wrote:
> To me, this is a somewhat unintuitive behavior. I want to discuss the
> parts of it I don't understand.
>
f= [ None ]* 10
for n in range( 10 ):
> ... f[ n ]= lambda: n
> ...
f[0]()
> 9
f[1]()
> 9
`n`
26 matches
Mail list logo
