Descent & Return

The route is not a loop. Output does not retrace the path input took. You descend through six layers of software to reach the processor, and then leave by an entirely different door — a syscall into the kernel, which hands your bytes to a different process that happens to be drawing letters. Nothing "returns" in the call-stack sense. Keeping that asymmetry in view is most of the battle.

You type python3 hello.py and press Return. Before a single byte of your file is read, the shell has to conjure a new process and pour a different program into it.

Bash searches $PATH directory by directory for an executable called python3, then performs the oldest trick in Unix: it calls fork() to clone itself, and the clone immediately calls execve() to replace its own program image with Python's. Same process ID, entirely new contents. The shell then blocks in wait() until the child dies — which is why your prompt doesn't come back until the program finishes.

$ file $(which python3)
python3.12: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
        dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
        BuildID[sha1]=bd4fbd1c…, for GNU/Linux 3.2.0, stripped

$ readelf -h $(which python3)
  Class:                             ELF64
  Data:                              2's complement, little endian
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Entry point address:               0x6576a0

$ ldd $(which python3)
  linux-vdso.so.1        ← kernel-injected fast-syscall page
  libm.so.6       => /lib/x86_64-linux-gnu/libm.so.6
  libz.so.1       => /lib/x86_64-linux-gnu/libz.so.1
  libexpat.so.1   => /lib/x86_64-linux-gnu/libexpat.so.1
  libc.so.6       => /lib/x86_64-linux-gnu/libc.so.6
  /lib64/ld-linux-x86-64.so.2

The thing about to "run" your program is itself a large, already-compiled C program that must set up an entire object universe before it can evaluate a single line.

Between main() and your first statement, CPython constructs a runtime: it allocates the interpreter and thread states, builds the builtins module so that names like print exist at all, sets up sys.modules, configures the import machinery, reads environment variables like PYTHONPATH, initialises the memory allocator's arenas, and takes the Global Interpreter Lock. Only then does it open hello.py.

$ python3 -c "import sys; print(len(sys.modules))"
33          ← modules already loaded before your first line

$ python3 -c "import sys; print(', '.join(sorted(sys.modules)[:14]))"
__main__, _abc, _codecs, _collections_abc, _frozen_importlib,
_frozen_importlib_external, _imp, _io, _signal, _sitebuiltins,
_stat, _thread, _warnings, _weakref

$ python3 -X importtime hello.py 2>&1 | tail -8
  self [µs] | cumulative | imported package
import time:        97 |         97 |       genericpath
import time:       164 |        363 |     posixpath
import time:       519 |       1958 |   os
import time:       107 |        107 |   _sitebuiltins
import time:        86 |         86 |   sitecustomize
import time:        31 |         31 |   usercustomize
import time:       371 |       2551 | site
total = 5

Python is compiled. It is compiled every time you run it, in milliseconds, to a target that is not your CPU.

Your file is read as text and pushed through four transformations. Each one is available to you directly from the standard library, which means you can watch the compiler work.

  NAME         'def'
  NAME         'add'
  OP           '('
  NAME         'a'
  OP           ','
  NAME         'b'
  OP           ')'
  OP           ':'
  NEWLINE
  INDENT          ← whitespace becomes a real token
  NAME         'return'
  NAME         'a'
  OP           '+'
  NAME         'b'
  NEWLINE
  DEDENT
  NAME         'total'
  OP           '='
  NUMBER       '2'

Module(
  body=[
    FunctionDef(
      name='add',
      args=arguments(
        args=[
          arg(arg='a'),
          arg(arg='b')]),
      body=[
        Return(
          value=BinOp(
            left=Name(id='a', ctx=Load()),
            op=Add(),
            right=Name(id='b', ctx=Load())))])])

# Not directly exposed, but you can see its verdict:
>>> add.__code__.co_varnames
('a', 'b')        ← decided to be LOCAL

>>> add.__code__.co_names
()                ← nothing global referenced

>>> compile(src,'x','exec').co_names
('add', 'total', 'print')   ← module scope: all global

  1  RESUME                   0
  1  LOAD_CONST               0 (<code object add>)
     MAKE_FUNCTION
     STORE_NAME               0 (add)
  4  LOAD_NAME                0 (add)
     PUSH_NULL
     LOAD_SMALL_INT           2
     LOAD_SMALL_INT           3
     CALL                     2
     STORE_NAME               1 (total)
  5  LOAD_NAME                2 (print)
     PUSH_NULL
     LOAD_CONST               1 ('total = ')
     LOAD_NAME                1 (total)
     FORMAT_SIMPLE
     BUILD_STRING             2
     CALL                     1
     POP_TOP
     LOAD_CONST               2 (None)
     RETURN_VALUE

Your bytecode is never executed by the CPU. It is read by a C program the way a CSV is read by a parser. This is the distinction everything else depends on.

The compiler's output is a code object — an ordinary Python object you can hold, inspect and pick apart. Its co_code field is a bytes object. Bytes. Data. Passive.

>>> c = add.__code__
>>> c.co_argcount      2
>>> c.co_nlocals       2
>>> c.co_stacksize     2       ← max value-stack depth, computed at compile time
>>> c.co_varnames      ('a', 'b')
>>> c.co_consts        (None,)
>>> c.co_names         ()

>>> c.co_code.hex(' ')
80 00 57 01 2c 00 00 00 00 00 00 00 00 00 00 00 23 00

>>> list(c.co_code)
[128, 0, 87, 1, 44, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 35, 0]

Every instruction is exactly two bytes

One byte of opcode, one byte of argument. Arguments larger than 255 are built up with EXTENDED_ARG prefixes. That regularity is what makes the interpreter loop fast — and what makes it possible to write your own in fifty lines, which we do next.

"The Python interpreter" is a single C function called _PyEval_EvalFrameDefault. It fetches a byte, jumps to the handler for that byte, mutates a stack, and repeats. That is the entire mystery.

Because your bytecode is just data, you can write your own interpreter for it in Python. This one is real: it executes the actual code object produced by the actual compiler, and gets the right answer.

import dis

def run(code, args=()):
    stack = []                                    # the value stack
    local = list(args) + [None] * (code.co_nlocals - len(args))
    instrs = list(dis.get_instructions(code, adaptive=False))
    ip = 0

    while ip < len(instrs):
        ins = instrs[ip]; ip += 1
        op, arg = ins.opname, ins.arg

        if op in ("RESUME", "NOP", "CACHE"):
            pass
        elif op == "LOAD_FAST":
            stack.append(local[arg])
        elif op == "LOAD_FAST_BORROW_LOAD_FAST_BORROW":
            stack.append(local[arg >> 4]); stack.append(local[arg & 15])
        elif op == "LOAD_SMALL_INT":
            stack.append(arg)
        elif op == "LOAD_CONST":
            stack.append(code.co_consts[arg])
        elif op == "STORE_FAST":
            local[arg] = stack.pop()
        elif op == "BINARY_OP":
            r = stack.pop(); l = stack.pop()
            stack.append({0: lambda a,b: a+b, 10: lambda a,b: a-b,
                          5: lambda a,b: a*b}[arg](l, r))
        elif op == "RETURN_VALUE":
            return stack.pop()
        else:
            raise NotImplementedError(op)

def add(a, b):
    return a + b

print(run(add.__code__, (2, 3)))

Step through the real thing

Below is the actual bytecode for hello.py, executed one instruction at a time. Watch the value stack, and watch the frame stack grow when add(2, 3) is called.

Bytecode that rewrites itself

Here is where the modern interpreter stops matching the textbook. Since 3.11, CPython ships a specialising adaptive interpreter: instructions watch the types flowing through them and, once confident, overwrite themselves in memory with a narrower, faster variant. Those ten zero bytes from station 4 are where the evidence is stored.

>>> def add(a, b): return a + b

>>> dis.dis(add, adaptive=True)          # cold
      RESUME                   0
      LOAD_FAST_BORROW_LOAD_FAST_BORROW 1 (a, b)
      BINARY_OP                0 (+)
      RETURN_VALUE

>>> for _ in range(500): add(2, 3)
>>> dis.dis(add, adaptive=True)          # after 500 int calls
      RESUME_CHECK             0
      LOAD_FAST_BORROW_LOAD_FAST_BORROW 1 (a, b)
      BINARY_OP_ADD_INT        0 (+)
      RETURN_VALUE

# and a twin fed strings instead:
>>> for _ in range(500): add2("x", "y")
      BINARY_OP_ADD_UNICODE    0 (+)

What changed, and when

Comparing the same function across versions is the quickest way to see the last decade of interpreter work:

─── Python 3.10 ────────────────────────────────
  2   0 LOAD_FAST                0 (a)
      2 LOAD_FAST                1 (b)
      4 BINARY_ADD
      6 RETURN_VALUE
      8 bytes · 4 instructions · one op per concept

─── Python 3.14 ────────────────────────────────
  2     RESUME                   0
        LOAD_FAST_BORROW_LOAD_FAST_BORROW 1 (a, b)
        BINARY_OP                0 (+)
        RETURN_VALUE
      18 bytes · 4 instructions + 10 bytes of cache

Everything on that value stack was a pointer. In CPython, id(x) returns the actual memory address of the object — which means you can reach into the process's own memory and read an object's internals with nothing but the standard library.

Every Python object begins with the same header: a reference count and a pointer to its type. A small integer adds a size field and the digits themselves. That is why the number 2 costs twenty-eight bytes.

>>> import sys, ctypes
>>> x = 12345678
>>> addr = id(x)
>>> addr
139780828826256   # == 0x7f2142a60a90 — a real heap address

# first 8 bytes at that address ARE the refcount:
>>> ctypes.c_ssize_t.from_address(addr).value
3
>>> sys.getrefcount(x)
4                # 4, because getrefcount's own argument counts

# next 8 bytes are the type pointer:
>>> hex(ctypes.c_void_p.from_address(addr + 8).value)
'0x15a46d0'
>>> hex(id(int))
'0x15a46d0'       # ← same. ob_type points at the int type object.

Small integers live somewhere strange

>>> id(2)
23047864          # 0x15faeb8 — low. static data in the binary.
>>> id(12345678)
139780828826256   # 0x7f21… — high. the mmap'd heap.

>>> a = 2; b = 2; a is b
True              # same object — preallocated at startup
>>> 5 is (2 + 3)
True              # your addition returned a pointer to a singleton

>>> sys.getrefcount(2)
3221225472        # 0xC0000000 — not a count. an IMMORTAL marker.
>>> sys.getrefcount(257)
7                 # an ordinary, mortal object

Where everything else comes from

For objects too big or too transient for that treatment, CPython does not call malloc per object. It runs its own allocator, pymalloc, three levels deep: it requests 1 MB arenas from the OS, carves them into 16 KB pools each dedicated to one size class, and hands out blocks in 8-byte increments. Allocating a small object is usually just popping a pointer off a free list.

>>> s1 = "total"; s2 = "total"
>>> s1 is s2
True       # identifier-like literals are interned by the compiler

>>> s3 = "".join(["to", "tal"])
>>> s3 == s1, s3 is s1
(True, False)   # equal value, different object — built at runtime

>>> sys.intern(s3) is s1
True       # forced into the intern table

We have reached the bottom. The CPU is executing _PyEval_EvalFrameDefault — compiled x86-64 machine code, indistinguishable to the hardware from a video codec or a kernel driver. Your bytecode is somewhere in its data cache, being read like a file.

The clean model

Every introduction starts here, and it is worth having, because it is the mental model the rest of the machine is pretending to honour:

What actually happens

The clean model has been a polite fiction since roughly 1995. A modern x86-64 core does all of the following at once, and the only contract it honours is that the observable results come out in program order:

• It decodes into micro-ops. Your x86 instruction is not the unit of execution. It is cracked into internal RISC-like μops, and frequently-executed loops are served from a μop cache that skips decoding entirely.
• It is superscalar. Four to eight μops are issued per cycle, to a set of specialised execution ports — several integer ALUs, a couple of load units, a store unit, vector units.
• It executes out of order. A reorder buffer holds hundreds of instructions in flight. If instruction 40 is waiting on memory and instruction 47 is ready, 47 runs first. Results are retired in order so you never notice.
• It renames registers. The sixteen architectural registers you can name are a fiction over a physical file of hundreds, which is how two independent uses of rax can run simultaneously.
• It speculates. At a branch, it predicts the outcome and executes down the predicted path immediately. Correct: free. Wrong: fifteen to twenty cycles of work thrown away.

The memory hierarchy, honestly scaled

The processor is fast. Memory is not. Everything about performance follows from the size of that gap:

$ lscpu | grep -i cache
  L1d cache:    32 KiB      ← ~4 cycles
  L1i cache:    32 KiB
  L2 cache:     1 MiB       ← ~14 cycles
  L3 cache:     33 MiB      ← ~50 cycles

The ratio that explains everything

One bytecode instruction — BINARY_OP in its generic form — costs somewhere between fifty and several hundred native instructions: decode, bounds-check, dispatch, unpack two PyObject*s, check types, look up __add__, perform the addition, allocate or fetch the result, adjust reference counts, push, advance the instruction pointer. The specialised BINARY_OP_ADD_INT collapses that to a guard and an add — perhaps a dozen. In C, a + b on two ints is one.

That spread, from one to several hundred, is the entire performance story of the language, and every optimisation in the 3.11–3.14 table above is an attempt to move the number leftward.

The turn. Everything so far happened inside one process's memory. To make anything appear anywhere, that process must stop, ask the kernel for a favour, and wait.

print() looks like one operation and is at least four. Your str passes down three stacked Python objects, becomes bytes, gets buffered, and eventually triggers a single write() syscall.

# run from a real terminal:
sys.stdout        -> _io.TextIOWrapper
  .encoding       -> utf-8
  .isatty()       -> True
  .line_buffering -> True        ← because it IS a tty
  .buffer         -> _io.BufferedWriter
  .buffer.raw     -> _io.FileIO
  .fileno()       -> 1

# exact same program, output redirected to a pipe:
  .isatty()       -> False
  .line_buffering -> False       ← now 8 KB block buffered

# buf.py
import sys, os
sys.stdout.write("A")              # goes into Python's buffer
os.write(2, b"[stderr marker]")   # raw syscall, no buffer
sys.stdout.write("B\n")

$ python3 buf.py
[stderr marker]AB

# The marker appears FIRST even though "A" was written first.
# "A" was still sitting in userspace memory when the raw
# write() to fd 2 went straight through to the kernel.

Your program is now finished — quite possibly exited — and the text still is not on screen. What happens next belongs entirely to someone else.

Your terminal emulator (GNOME Terminal, Alacritty, kitty, foot) has been sitting in poll() on the master end of the pseudo-terminal since before you typed the command. The kernel marks it readable; the emulator wakes.

The display controller does not know it is showing text. It reads a rectangular array of colour values out of VRAM, sixty or more times per second, and shifts them out over a cable. Somewhere in there, ten of those values are arranged in the shape of a 5.

Does Debian change any of this?

Stations 7 through 9 are pure kernel and hardware — the distribution is irrelevant there. Stations 1 through 6 are affected only in packaging, but the packaging has teeth:

The asterisk: does your bytecode ever become machine code?

Station 4 claimed your bytecode is never executed by the CPU — only read. That is true of every Python you are likely to be running, and it is the right model to hold. But it is worth knowing exactly where the edge is, because there are two very different things people mean by "JIT" and only one of them is genuinely new.

What you have been using since 3.11

The specialising adaptive interpreter from station 5. Instructions rewrite themselves into narrower variants. Nothing is compiled to machine code — BINARY_OP_ADD_INT is still a bytecode instruction, still dispatched by the same while loop, just cheaper. The model holds completely. This is on by default and it is why 3.11+ is meaningfully faster than 3.10.

What arrived in 3.13, experimentally

A copy-and-patch JIT. CPython identifies hot straight-line traces, and instead of dispatching through the loop, stitches together pre-compiled machine-code templates — one per micro-op — patching in the actual constants and pointers. For those traces, real x86-64 instructions derived from your Python are executed by the CPU, and station 4's claim gets its asterisk.

Three reasons not to reorganise your mental model around it: it must be enabled at build time and is off in every mainstream distribution including Debian; it covers a small fraction of executed code; and it changes performance, not semantics. The eval loop is still in charge. The JIT is an optimisation that some traces get to skip into, not a replacement for interpretation.