How Is Python Code Executed?

Taking a function apart and showing its instructions is the fastest way to prove that Python compiles before it interprets. The dis module prints the instructions of a code object, and it groups them by the line of source code that produced them.

import dis


def average(values):
    total = sum(values)
    return total / len(values)


dis.dis(average)

The output falls into four groups. The first group is the start of the function. That is RESUME, which in version 3.11 and later marks the beginning of a frame, and then a LOAD_FAST for each parameter and local name. The second group is the call to the built-in sum. It uses LOAD_GLOBAL to find the name, then LOAD_METHOD or PRECALL and CALL to make the call, and then STORE_FAST to keep the result in total. The third group is the arithmetic, with a fresh LOAD_FAST for total and for len, a BINARY_OP for the division, and then RETURN_VALUE to hand the result back to the caller.

Two details make the answer sharper. The bytecode belongs to the CPython implementation and it changes between versions, so it is not a portable contract in the way that Java's class file format is. And every line of source maps to a group of instructions, which means the dis output reads like your source code with the order of evaluation written out in full.

For an interview this is a strong demonstration, because it connects the general claim that Python compiles to bytecode with something you can actually show. If you would rather look at the same information without the instruction listing, you can read the attributes of the code object directly. co_names holds the global names that the function uses, co_consts holds the literal values, and co_varnames holds the names of the local variables.

Every Python program passes through four stages, and interviewers like to hear them described precisely.

The first stage is tokenising. The source text is broken into tokens, which are names, numbers, strings, operators, keywords, and punctuation. The tokenizer also deals with the indentation, and it turns it into INDENT and DEDENT tokens. That is why indentation is part of the grammar and not just a way of formatting the text.

The second stage is parsing. The stream of tokens is organised into a tree, which is called the abstract syntax tree, or the AST. Each node in the tree stands for one piece of the program, such as an assignment or a function call. The tree records the structure and the nesting of the program, and it holds no reference to the original layout of the text.

The third stage is compiling. The tree is walked and turned into bytecode, which is a low-level set of instructions that the virtual machine inside CPython carries out. Alongside the bytecode, the compiler builds a code object that holds the constant values, the names, the slots for local variables, and the line numbers. That code object is what lets a traceback point back at the original line of your file.

The fourth stage is execution. The interpreter loop reads the instructions from the code object and carries them out, while it keeps a stack of frames with one frame for each function call that is still running. Importing a module is part of this stage. It means finding the module on sys.path, compiling it if that has not been done yet, creating a module object, and running the code at the top level of the module inside a brand new namespace.

The result of the third stage is saved on disk. CPython writes the bytecode into a __pycache__ folder as a .pyc file, and the name of that file is based on the modification time and the size of the source file. Later runs skip the parsing and the compiling completely, and that cache is why the second run of a script starts noticeably faster than the first one.