Why does a Python list comprehension's loop variable not leak into the enclosing scope?

## The rule In Python 3, every list, set and dict comprehension, and every generator expression, evaluates its body in a scope of its own — an *implicit function scope*. Any name bound by its `for` clauses, including names produced by tuple unpacking such as `for k, v in pairs`, lives and dies inside that scope. Code in a comprehension cannot create or overwrite a variable in the code around it. There are exactly two documented ways out, both of which are separate topics: an assignment expression (`:=`), which is specified to bind in the containing scope, and the outermost iterable, which is evaluated in the enclosing scope before the comprehension's own scope exists. ```python row = "header" widths = [len(row) for row in ("aa", "bbb")] print(widths) # [2, 3] print(row) # 'header' — untouched ``` The comprehension shadowed `row` for the duration of the loop and then vanished, leaving the outer binding exactly as it was. ## Why it works this way Python 2's list comprehensions were defined as syntactic sugar for a `for` statement executed in the current scope, so they leaked: after `[x for x in range(3)]` the name `x` survived, bound to `2`. That was a frequent source of quiet bugs — a comprehension in the middle of a function silently clobbered a variable defined above it. Generator expressions, added later, were compiled to a real generator function from the start and therefore never leaked, so Python 2 shipped two comprehension-like constructs with different scoping. Python 3 resolved the inconsistency by giving list, set and dict comprehensions the same isolation the generator expression already had. ## How CPython implements it Through Python 3.11 the implementation was literal: the compiler synthesised an anonymous function — you can see it in `dis` output and in tracebacks under the name `<listcomp>`, `<setcomp>`, `<dictcomp>` or `<genexpr>` — and called it immediately, passing the already-evaluated outermost iterable as its single argument. The loop variable was simply a local of that hidden function. Python 3.12 changed the implementation without changing the rule. PEP 709 *inlines* list, set and dict comprehensions into the enclosing code object: there is no function object to create and no call to make, which makes short comprehensions substantially faster (the PEP measured up to about twice as fast). Isolation is preserved by the compiler instead of by a call frame — if the enclosing scope already has a variable of the same name, it is saved before the loop and restored afterwards. The observable effects of the change are that a traceback raised inside a comprehension no longer shows an extra `<listcomp>` frame, and that profiling no longer attributes time to a separate function. Generator expressions are *not* inlined; they still compile to a real generator function, because their body must be able to suspend. So the isolation is a language guarantee that has held since Python 3.0, and the 3.12 work is an optimisation underneath it. Nothing you write should depend on which mechanism is in use. ## Isolation is only about binding The comprehension's scope is nested inside the code that contains it, so reading names works normally: enclosing function locals are reachable as closure variables, module globals and builtins resolve as usual. ```python def scale(values): factor = 10 return [v * factor for v in values] # factor read from the enclosing function ``` Only *creating or rebinding* a name is contained. That is precisely the asymmetry that makes comprehensions safe to drop into existing code: they consume the surrounding namespace but never mutate it. ## What still leaks A `for` statement is not a scope. After a plain loop, its target is still bound, holding the last value produced — and if the iterable was empty, it is not bound at all, which is why code that reads the loop variable after the loop can raise `NameError` on empty input. `while` loops, `if` blocks and `with` blocks are likewise not scopes. In Python, only modules, functions (including the implicit ones behind comprehensions), classes and, since 3.12, the annotation and type-parameter scopes introduce a new namespace. ## What interviewers are checking Three things, in order. First, that you know the loop variable does not survive — so you cannot use the Python 2 idiom of reading it afterwards. Second, that you know the mechanism is a scope rather than a `del` at the end, which is what predicts the shadowing behaviour: an outer variable of the same name keeps its value rather than being deleted. Third, that you do not overgeneralise the rule to `for` statements, which is the mirror-image mistake and shows up in real code as a variable that unexpectedly still holds the last item.