Why does assigning into locals() inside a Python function not change the variable?

Python compiles function bodies into what the interpreter calls an *optimized* scope: the compiler knows every local name at compile time and assigns each one a numbered slot on the frame, so reading `x` inside a function is an index into an array, not a dictionary lookup. That single optimization is the source of the whole `locals()` confusion. There is no dictionary of local variables to hand you — one has to be *manufactured* on request. ### Before 3.13 In Python 3.12 and earlier, both `locals()` and a frame's `f_locals` attribute produced the same thing inside a function: a dictionary snapshot, built by copying the current value of every slot. Writing into that dictionary changed the copy and nothing else, and the next access rebuilt the snapshot from the slots, silently discarding your write. So: ```python def f(): x = 1 locals()["x"] = 2 print(x) # 1 on every version ``` The only exception was a debugger: while a trace function was active, the interpreter had a write-back step that pushed the snapshot's contents into the real slots, which is how a debugger could let you assign to a local at a breakpoint. That write-back was famously unreliable and was the motivation for changing the design. ### PEP 667, shipped in Python 3.13 PEP 667 split the two behaviours that had been conflated. * `frame.f_locals` in a function scope now returns a **write-through proxy** rather than a snapshot. Reads go straight to the frame's slots, so it is always current, and writes go straight back into the slots, so an assignment through it really does change the variable. * `locals()` inside a function is now explicitly defined to return an **independent snapshot dict**. Mutating it is guaranteed to have no effect on the function's variables, and each call returns a fresh dict rather than repeatedly refreshing one shared object. ```python import sys def f(): x = 1 locals()["x"] = 2 print(x) # 1 — snapshot, write discarded sys._getframe().f_locals["x"] = 3 print(x) # 3 on 3.13+, 1 on 3.12 and earlier ``` That is the whole interview answer: since 3.13, `f_locals` writes through and `locals()` does not, and before 3.13 neither did. ### The asymmetry that trips people up At module level and inside a class body, the scope is *not* optimized — names really do live in a dictionary — and `locals()` returns that actual mapping. So `locals()["x"] = 2` at module level does create a usable `x`. People generalize from a REPL experiment to function bodies and are wrong, because the two scopes have genuinely different storage. The same applies to `exec("x = 1")` inside a function: the assignment lands in whatever mapping `exec` was given — by default the snapshot — and evaporates. `exec` cannot create a local variable in a compiled function, on any version. There is one more edge worth knowing. Writing a name through the proxy that the function never declares as a local has nowhere to go in the slot array, so the frame stores it in an extra side-mapping. It is visible if you read `f_locals` again, but the compiled bytecode never looks there — the compiler already decided that name was a global — so reading it as a bare name raises `NameError`. The proxy is a way to set variables the function *has*, not a way to inject new ones. ### Why any of this matters in practice Three groups of people care. Debugger and REPL authors care because "set this variable and continue" is a core feature, and PEP 667 is what made it dependable rather than a trace-hook trick. Template and dependency-injection libraries care because they are tempted to read a caller's locals to resolve names — the proxy makes that read cheap and always current, but it does not make the coupling a good idea. And everyone else cares for the negative reason: it explains why the tempting one-liner — build a dict, dump it into `locals()`, get free variables — has never worked and, for `locals()`, is now specified never to work. The practical rule: treat `locals()` as a read-only reporting snapshot, use `f_locals` only in tooling that is knowingly reaching into another frame, and bind variables the ordinary way — with assignment statements the compiler can see.