Comments on: Python’s lambda is broken!

By: John Powell

John Powell — Mon, 11 Jul 2011 15:28:41 +0000

Following on from what Svat said, in introductory javascript books, there is always a warning about assigning event listeners in loops with the value for the loop exit condition being assigned, instead of the 1, 2, 3, etc expected. The solution given is to use a closure and the (function(n){})(n); construct.
[/sourcecode]
var fs = {};
for(var i=0; i<5; i++) {
fs[i]= (function(i){
return function(n) { return n+i; }
})(i);
}

for(var j in fs) {
console.log("fs[" + j +"] =" ,fs[j](100));
}

I am reasonably new to functional programming, but the supposed “issue” with python seems quite reasonable when viewed through javascript eyes.

By: Matteo

Matteo — Wed, 18 May 2011 19:58:01 +0000

Well this is my first try with Ruby:

fns = (0..9).collect {|i| lambda {|n| i + n}}

p fns[3].call(4)

indeed it prints 7 :-)

By: Frank Atanassow

Frank Atanassow — Sun, 08 May 2011 17:09:15 +0000

Andrej, was just checking back and noticed someone had already given my explanation about location vs. value. Then I noticed your remark about the comprehension leaving i in the global scope. (I agree this is laughable.) I wondered if my explanation was wrong and Python was just referencing the leftover global i. Actually, it seems both explanations are right, since you can alter the value of the closure by assigning to the leftover global!

>>> i=2 >>> i 2 >>> fs = [(lambda n: i + n) for i in range(10)] >>> fs[3](0) 9 >>> i 9 >>> i = 0 >>> fs[3](4) 4

By: Frank Atanassow

Frank Atanassow — Sat, 07 May 2011 22:33:44 +0000

I know this discussion is long since over, but I recall talking about the very same issue recently on somebody else’s blog and, as far as I can see, all the explanations here are incorrect. (All the ones there were too; it’s tricky.) The issue is not scoping or broken lambda-expressions; rather, it depends on the fact that Python implements list comprehensions via mutation.

For my reference and yours, here is your first example:

>>> fs = [(lambda n: i + n) for i in range(10)] >>> fs[3](4) 13

When the lambda-expression is evaluated, the variable i is properly captured in a closure. In Python, a variable is, as you know, a reference to a mutable cell. However, Python list comprehension is evaluated by updating i for each element in the domain, not rebinding it. This means that you are creating 10 closures with 10 copies of references to the same mutable cell. By the time fs is bound, the comprehension has been evaluated, so the value in the cell is 10, so each dereference will return 10.

In contrast, in Ocaml the for-do construct is implemented by rebinding the index for each evaluation of the body. However, if you were to implement list comprehensions using camlp4 in the same way as Python, by mutation, you might encounter the same problem in Ocaml, depending on whether you you capture the cell or its contents.

This code, which is the natural and erroneous solution:

[ (fun n -> !i + n) for i in 1 to 10]

would behave like the Python code, because the cell is captured and only dereferenced after the list is built.

This code:

[ let i' = !i in (fun n -> i' + n) for i in 1 to 10 ]

would behave as you expected, because i is dereferenced while the list is being built.

I don’t know if Python provides a way to get the same effect (I am a Haskeller); it displays the usual imperative confusion between variables and cells. But I think I’ve demonstrated that, at least in this respect, Python’s lambda does not behave any differently than you would expect an ML language’s to behave.

By: Lambda expressions in Python « dsimkhada

Lambda expressions in Python « dsimkhada — Fri, 08 Apr 2011 18:38:52 +0000

[...] http://docs.python.org/reference/expressions.html#lambda [2] http://math.andrej.com/2009/04/09/pythons-lambda-is-broken/ [3] http://diveintopython.org/power_of_introspection/lambda_functions.html [4] [...]