What does Python's locals() return inside a function, and does writing to it change a local?

## Why the two functions differ so much `globals()` and `locals()` sound symmetric and are not, because the namespaces behind them are stored in completely different ways. A module's namespace genuinely *is* a dictionary — the one attached to the module object — so `globals()` can return it directly. It is live: put a key in it and you have created a module-level name; rebind a key and every later bare-name read of it in that module sees the new value. A function's locals are not a dictionary. While compiling the function the interpreter fixes the set of local names and assigns each a slot in an array on the frame, which is what makes local access an array index rather than a hash lookup. There is nothing dictionary-shaped to return, so `locals()` materialises one by copying the slots into a fresh mapping. ## What changed in 3.13 Historically CPython kept one dictionary on the frame and re-populated it on each `locals()` call. That produced genuinely confusing behaviour: mutations to the returned dict survived until something refreshed it, and whether they survived depended on tracing, debuggers, and which build you were on. **PEP 667, shipped in Python 3.13**, made the semantics explicit: in an optimised (function) scope, `locals()` now returns an independent snapshot on every call. Two calls return two different dicts, and neither is connected to the running variables. Debuggers keep the ability to *write* locals through a separate write-through view of the frame, which is the supported mechanism — `locals()` is not. ```pycon >>> def f(): ... x = 1 ... snap = locals() ... snap["x"] = 99 ... return x, snap["x"], locals() is snap ... >>> f() (1, 99, False) ``` The local `x` is still `1`, the snapshot says `99`, and the second call produced a different object. ## The practical rule Treat `locals()` in a function as read-only introspection. It is fine for logging — dumping the arguments and working values of a failing call — and fine for formatting, as in building a message from a mapping of current values. It is not a mechanism for creating variables dynamically. Code that tries `locals()[name] = value` to synthesise a local silently does nothing; the honest alternatives are a dictionary you own, `setattr` on an object, or a small class. `globals()` is a real write path, and that is precisely why it deserves suspicion. `globals()[name] = value` genuinely defines a module-level name, so it is occasionally used by registration and plugin code, but it defeats every static tool: linters, type checkers, IDE navigation and readers all lose track of where the name came from. Prefer an explicit registry dictionary, and reach for `globals()` only where the dynamic definition is the point. ## The other two scopes At module level, `locals()` and `globals()` return the same object — `locals() is globals()` is `True` — because the module's local namespace *is* its global namespace. In a class body, `locals()` gives the class namespace as it is being built, which is how some metaclass and DSL tricks read what has been defined so far. In a comprehension or a generator expression the result reflects that construct's own implicit scope, not the surrounding function's. ## Interview shape The question is usually posed as a snippet: assign to `locals()` and ask what the variable is afterwards. The answer is that the variable is unchanged, and the reason is the storage model — the array of slots on the frame is the source of truth and the dict is a copy of it. Naming PEP 667 and the 3.13 change is what separates a memorised gotcha from an understood one, because it explains why older answers on the internet disagree with what the reader observes today. Being able to contrast that with `globals()`, which really is live, shows you understand the mechanism rather than the rule.