F10: inside a code object

[tamnd]

F09 ended with a code object falling out of the assembler. This one opens it up.

The hook is that a code object holds no values. Not one. It has the instructions, the literals, the names to look up later and the list of slots a frame will need, and every actual value your program computes lives somewhere else. That is what makes one code object able to serve every call, and it is the thing to have straight before F13 builds a frame.

What is in it

It starts by compiling a small file with a class, a method and a generator in it, then walking co_consts recursively. A nested definition is not a separate thing the compiler hands back alongside the module, it is stored as a constant of the enclosing code object, sitting next to the numbers and the strings. Printing the tree makes that concrete in about four lines.

The part that earns the lesson is localsplus. co_varnames, co_cellvars and co_freevars read like three tuples and are three filtered views of one array, and for def outer(a, b=2, *args, c, **kw) with a nested function reading a, the array has seven slots and the three tuples add up to eight. a is tagged both local and cell, get_localsplus_names tests one bit at a time, and so a comes out of two of the filters. The lesson enumerates the real array with _varname_from_oparg and prints which tuples each slot turns up in, which makes the overcount obvious rather than surprising.

That tag is also the answer to a question a reader has probably had for a while, which is why dis sometimes shows two instructions before the first line of the function. MAKE_CELL 0 has to replace the value in slot 0 with a cell holding it before anything can read it, so it runs before your code does.

Equality

code_richcompare compares the name, the argument counts, the flags, the first line number, the constants, the names, the side tables, and the bytecode through _Py_GetBaseCodeUnit, which is the unspecialized form. It never compares co_filename. So the same source compiled from /one/place.py and from /somewhere/else.py gives two code objects that are equal and hash the same, and the filename is carried for tracebacks rather than for identity.

The specialization half is nicer than it sounds. Run a function five thousand times, and it still equals a fresh compile, and co_code is byte for byte identical, and _co_code_adaptive underneath it is not. Three lines, and the reader has seen the quiet copy the interpreter has been writing into the whole time.

Then replace, which gives a new object rather than changing this one, and the AttributeError you get for assigning to co_name, printed rather than described.

The usual

Eighteen cells, six diagrams, six claims each with a runnable cell under it and no unobservable ones, eight citations into Include/cpython/code.h, Include/internal/pycore_code.h, Objects/codeobject.c and Python/assemble.c. No new glossary terms: code object, frame, cell and the rest were all already in there. One version note, the usual one saying which interpreter you are on. just check passes and the notebook runs top to bottom on Pyodide as well as on 3.14 and 3.15.

F11 takes the two side tables this one only names, the line table and the exception table.