Why does every lambda in [lambda: i for i in range(3)] return 2?

**The rule in one line: a nested function stores a reference to the variable it captured, and reads that variable when the function is called.** Python calls this *late binding*. Nothing about `lambda`, comprehensions or lists is special here — the same rule governs every function defined inside another scope. ### What the comprehension actually builds `[lambda: i for i in range(3)]` runs three iterations. Each iteration evaluates the `lambda` expression, and evaluating a `lambda` **creates a new function object**; it does not execute the body. The body is just the name `i`, and nothing looks it up yet. After three iterations you hold three distinct function objects, and the comprehension's iteration variable has finished at 2. Then you call them. Each call executes the body. `i` is not a parameter of the lambda and is not assigned inside it, so it is a *free variable*: it is resolved in the scope that enclosed the lambda when it was created, and that scope's `i` now holds 2. Three separate function objects, one shared variable, one answer: `[2, 2, 2]`. Two things are commonly confused here, and separating them is most of the answer: 1. **Which** variable a nested function reads is decided when the code is compiled, from where the name is bound. 2. **What value** that variable holds is decided when the function runs. Late binding is entirely about (2). ### The same trap without a comprehension ```python funcs = [] for i in range(3): funcs.append(lambda: i) print([f() for f in funcs]) # [2, 2, 2] ``` Identical output. The only difference between the loop and the comprehension is scope hygiene: after a `for` loop the loop variable is still bound in the enclosing function, so `print(i)` shows 2; a comprehension keeps its variable to itself, so you cannot see it afterwards — even though the lambdas can. A tiny example makes the timing obvious without any loop at all: ```python def build(): x = 1 f = lambda: x x = 99 return f print(build()()) # 99 ``` The function was created while `x` was 1 and still reports 99, because the read happens at call time. ### The fixes: one new binding per iteration Every working version does the same thing — gives each callable a binding created during that iteration. Python creates a fresh binding on a *call*, in the form of parameters, so all three standard fixes are ways of turning the loop value into a parameter. * **Default parameter.** `[lambda i=i: i for i in range(3)]` yields `[0, 1, 2]`. A default value is evaluated once, when the `lambda` expression executes, so each object stores that iteration's value; inside the body the parameter shadows the enclosing name. The cost is a public parameter that a caller can override. * **`functools.partial`.** `partial(check, i)` records `i` when the partial object is created and supplies it when the object is called. The underlying function stays an ordinary named function taking the value as a parameter. * **A factory function.** An outer function that takes the value as a parameter and returns the inner function. The most explicit, and the only one that still reads well when the inner function is more than a single expression. What does *not* work is rebinding to another name inside the loop: `j = i` creates another variable in the same scope, and it moves on with the loop exactly as `i` does. ### Where it actually bites Almost never in a REPL, where you call the function immediately and it happens to be right. It bites when the calls are **deferred**: handlers registered in a loop, a dispatch table built from a list of names, wrappers applied per item, work items queued for later. None of them raise; they all "work"; they simply all agree, and they agree on the last item. That is why the real-world symptom is usually every consumer reading one wrong value rather than a traceback. ### Version notes Python 3 gave comprehensions their own scope, which is why the iteration variable does not leak into the surrounding function (Python 2's list comprehensions leaked it). Python 3.12 inlined comprehensions as an optimization (PEP 709) while preserving those scoping semantics, and 3.14 behaves the same way: lambdas built in a comprehension still read the iteration variable at call time and still return `2, 2, 2`. ### What to say in an interview Predict the output, state the rule, name at least two fixes, and say where you have hit it in real code. One sentence shows you understand it rather than memorized it: *the function captured the variable, not the value, and the variable is read when the function runs.*