The Secret Compiler Inside Python

Installing mental model for python internals.

Python is an interpreted language. You've heard it a thousand times. You write code, Python reads it line by line, and runs it. Simple. No compilation. No binary. Just text in, results out.

Except... that's not what happens. Not even close.

Let me show you. Take this function. Two lines. Adds two numbers. Nothing fancy.

Now watch. Import dis. Call dis.dis on that function. And look what comes out.

Load fast. Load fast. Binary op. Return value.

That's bytecode. Compiled bytecode. Python's compiler turned your function into a sequence of low-level instructions before it ever ran a single line.

Still think Python is interpreted?

There's more. Check your project folder. See that pie-cache directory you've been ignoring? Open it. Those dot-pie-see files? That's compiled bytecode — cached on disk so Python doesn't have to recompile next time.

Python has a compiler. It always has. You just never see it run.

So what actually happens when you hit "run"?

Your source code goes through a real compilation pipeline. Three stages, all hidden, all automatic.

First — the tokenizer rips your code apart. Every keyword, variable, operator becomes a labeled token. Def. Name: add. Open paren. Your clean source code? Now a stream of tagged pieces.

Then the parser assembles those pieces into a tree — an Abstract Syntax Tree. It captures structure. The function contains a return. The return contains an addition. The addition has two operands. Flat text becomes hierarchy.

And finally — the compiler. This is the one nobody talks about. It walks that tree and emits bytecode. A compact sequence of instructions for a virtual machine. Not machine code. Not native CPU instructions. But real compiled output, saved in those dot-pie-see files.

Three stages of compilation, hidden behind a single command: python your_script.py.

Now for the final stage. The bytecode needs something to run it. That's the C-Python virtual machine — a stack-based interpreter.

Think of it as a simple machine with one core idea: everything goes through a stack. Values go on, values come off.

Let's step through our add function. The VM reads the first instruction: load fast A. It grabs the value of A and pushes it onto the stack. Next: load fast B. Grabs B, pushes it on top.

Now: binary op add. The VM pops the top two values off the stack, adds them together, and pushes the result back on.

Finally: return value. Pop the result off the stack, and that's your answer. Four instructions. That's all it took.

This is what Python actually does with your code. It doesn't read your text and figure things out on the fly. It compiles to bytecode, then a virtual machine executes that bytecode instruction by instruction. Compiled, then interpreted. Both.

That's why calling Python "interpreted" is wrong. The VM does interpret bytecode — but it completely ignores that Python compiles your code first.

So if Python compiles code, why is it still slow?

Because of what happens AFTER compilation. When C compiles, the output is native machine code. Your CPU runs it directly. An add instruction executes in nanoseconds.

But Python's compiler targets a virtual machine, not your CPU. Every bytecode instruction gets fetched, decoded, and dispatched by the interpreter loop. Then the VM checks types — is this an integer? A float? Then it unboxes the values, computes the result, boxes it back up. What C does directly in hardware, Python does through layers of software.

That's the real cost. Not the lack of compilation — but the overhead of interpreting each instruction through software instead of hardware.

And there's one more secret hiding in Python's interpreter. A lock that prevents more than one thread from running bytecode at the same time. It's called the gill. But that's a story for another video.

If you want to see that story — subscribe. Next time, we're going inside the GIL.

Cognitive architecture... updated.