What does a Python function's __code__ attribute give you?

## Two objects behind every `def` A Python `def` statement produces **two** distinct objects at two distinct moments, and `__code__` is the link between them. When CPython compiles a module, each `def` in the source is compiled into a **code object** — an immutable object holding the bytecode for that function's body plus every fact the compiler could work out statically. That happens once, at compile time. Later, when the module actually *runs* and control reaches the `def` statement, CPython creates a **function object** and points its `__code__` attribute at the code object that was already compiled. Executing the same `def` a second time (a factory called twice, a decorator applied twice, a method defined inside a loop) creates a second function object over the *same* code object. ## What the code object carries The attributes are conventionally prefixed `co_`: * `co_name` and `co_qualname` — the name written in the source (`co_qualname`, the dotted qualified name, was added in 3.11). Rebinding `f.__name__` does **not** change `co_name`, which is why tracebacks keep showing the original name. * `co_filename` and `co_firstlineno` — where the source lives. Tracebacks are rendered from these. * `co_argcount`, `co_posonlyargcount`, `co_kwonlyargcount` — how the parameter names in `co_varnames` split into positional-only, positional-or-keyword and keyword-only. * `co_varnames` — the tuple of local-variable names, parameters first. These are compiled to fixed integer slots. * `co_names` — names that must be resolved by name at run time: globals, builtins, attribute names, imported module names. * `co_consts` — the constants the compiler baked in: literals, the results of constant folding, the docstring if there is one, and a nested code object for every `def` or `class` in the body. * `co_flags` — a bitfield. `inspect.CO_GENERATOR`, `inspect.CO_COROUTINE`, `inspect.CO_ASYNC_GENERATOR`, `inspect.CO_VARARGS` and `inspect.CO_VARKEYWORDS` are the bits worth knowing; `inspect.isgeneratorfunction` and `inspect.iscoroutinefunction` are the readable front ends for them. * `co_stacksize`, `co_freevars`, `co_cellvars` and the raw `co_code` round it out. ```python def area(w, h=2): return w * h print(area.__code__.co_varnames) # ('w', 'h') print(area.__code__.co_argcount) # 2 print(area.__code__.co_consts) # (None,) print(area.__defaults__) # (2,) ``` Notice the last two lines: the default `2` is **not** in `co_consts`. It is on the function. ## What the code object does not carry Everything whose value depends on when the function object was created stays on the function: `__defaults__` and `__kwdefaults__`, `__globals__` (the module namespace the function will resolve globals in), `__closure__`, `__dict__` (attributes you attach to the function), `__module__`, and `__doc__` — the docstring starts out as `co_consts[0]`, but assigning `f.__doc__` changes only the function, leaving the code object untouched. Since 3.14, annotations are computed lazily through the function's `__annotate__` and `__annotations__`, again on the function, not the code. ## Immutable, shared, and swappable Code objects cannot be mutated. `types.CodeType.replace` returns a *new* code object with some fields changed, which is how instrumentation tools adjust a filename or a line number. What you *can* do is rebind the attribute: `f.__code__ = g.__code__` swaps the body of `f` wholesale, subject to one check — the new code object must want the same number of free variables, otherwise CPython raises `ValueError`. That trick is the basis of some hot-patching and coverage tools; it is not something to reach for in application code. ## Code objects without a `def` The built-in `compile()` hands you one directly, for a whole module or a single expression, which is the quickest way to inspect what the compiler produced: ```python mod = compile("def outer():\n def inner():\n pass\n", "<s>", "exec") print(mod.co_consts[0].co_consts[0]) # <code object inner ...> ``` Nested definitions nest the same way in the constants tuple: the module's code object holds `outer`'s code object, which holds `inner`'s. `dis.code_info` prints a readable summary of any of them, and `types.FunctionType(code, globals)` turns one back into something callable. That round trip is the clearest proof of what the two objects are for — the code object is the compiled artefact, the function object is the thing that can be called. ## Why interviewers ask The question separates people who think a function *is* its body from people who know a function is a small runtime record pointing at a compiled body. That distinction explains decorators, `functools.wraps`, why mutable default arguments persist, why a traceback names a function you thought you had renamed, and how introspection tools work — so it is worth being able to name three or four `co_` attributes without hesitating.