Code Objects

## Compile time versus definition time The confusion this question targets comes from collapsing two separate moments into one. **Compile time** is when CPython turns source text into bytecode. Every `def` in the source yields exactly one immutable code object, holding the body's bytecode plus static metadata (`co_argcount`, `co_varnames`, `co_names`, `co_consts`, `co_flags`). **Definition time** is when the `def` statement is *executed* — when the module is imported, or every time the enclosing factory function is called. At that instant CPython builds a **function object**: a small record binding the already-compiled code object to everything that could only be known now. A default value falls squarely on the second side of that line. `def f(x=[])`, `def f(x=compute())` and `def f(x=factor)` are all legal, and Python cannot precompute any of them at compile time — the first allocates a mutable object, the second calls a function, the third reads a name from the enclosing scope. So the compiler emits code that *evaluates the default expressions* as part of executing the `def`, and stores the resulting values on the function object. ```python def make_scaler(factor): def scale(value, factor=factor): return value * factor return scale double, triple = make_scaler(2), make_scaler(3) print(double.__code__ is triple.__code__) # True print(double.__defaults__, triple.__defaults__) # (2,) (3,) ``` One compiled body, two function objects, two different default tuples. ## Where each piece lives On the **code object** (static, immutable, shared): bytecode, `co_name`, `co_filename`, `co_firstlineno`, argument *counts*, local and global *names*, folded constants, flags. On the **function object** (per definition): `__defaults__` (a tuple, one entry per positional parameter that has a default, right-aligned), `__kwdefaults__` (a dict for keyword-only parameters), `__globals__` (the module namespace this function resolves globals through), `__closure__`, `__name__`, `__qualname__`, `__doc__`, `__module__`, `__dict__`, and since 3.14 the deferred `__annotate__` used to produce `__annotations__` on demand. Both `__defaults__` and `__kwdefaults__` are writable, which is a legitimate way to re-arm a function without redefining it: ```python def collect(items=[]): items.append(1) return items print(collect()) # [1] print(collect()) # [1, 1] - one shared list collect.__defaults__ = ([],) print(collect()) # [1] - re-armed with a fresh list ``` ## The consequence everyone meets first Because the default object is created once and held by the function, a mutable default accumulates across calls. The habitual fix is a `None` sentinel and a fresh object inside the body. The deeper point for an interview is the *reason*: the value could not have been stored on the shared, immutable code object, because two functions compiled from the same `def` may legitimately need different defaults — as `make_scaler` above shows. The same reasoning explains a family of related facts. `__globals__` is per function, so a function moved between modules by assignment still resolves globals in the module it was *defined* in. Class bodies executed twice produce methods sharing code objects but with separate function objects, which is what lets a decorator applied at definition time attach per-function state. And `types.FunctionType(code, globals, name, defaults)` makes the split explicit: you hand it a code object plus exactly the per-definition pieces. ```python import types def greet(name="world"): return f"hi {name}" clone = types.FunctionType(greet.__code__, greet.__globals__, "clone", ("there",)) print(clone(), greet()) # hi there hi world ``` Same compiled body; a different default supplied at construction. ## The same split, seen from a decorator A decorator runs at definition time, which is exactly why it can see and adjust the per-definition pieces: it receives the freshly built function object and can read `__name__`, `__doc__`, `__defaults__` and `__dict__` off it. What it cannot touch is the compiled body — that code object is fixed and shared. A wrapper is therefore a *second* function object with its own defaults and its own `__globals__`, which is why `functools.wraps` exists at all: without it the wrapper advertises its own metadata rather than the wrapped function's. Class bodies show the split too. Every method is a function object built when the class body executes, over a code object compiled once. Defining the same class twice — a class created inside a factory, a module imported under two names — produces new function objects sharing the old compiled bodies, and each of those function objects carries its own defaults. ## Answering it well Say the two moments out loud — compiled once, defined possibly many times — then name where the pieces live, then give one consequence. Avoid the two common wrong turns: claiming defaults are re-evaluated on every *call* (they are not; that would make the mutable-default behaviour impossible), and claiming each `def` execution recompiles the body (it does not; only the function object is new).