{"title":"Python Interpreter","description":"","content":"You type `python checkout.py` and a line of output appears. Between those two things, Python does more work than the word \"interpreted\" suggests. This chapter traces what happens from the moment you save a `.py` file to the moment your CPU runs the code, and clears up the most common misconception about Python: that it's just an interpreter reading your source line by line.\n\n---\n\n# The Big Picture\n\nPython's execution pipeline has two halves. The first half compiles your source code into bytecode. The second half feeds that bytecode to the Python Virtual Machine (PVM), which executes it instruction by instruction. Both halves usually happen inside the same `python` process, in the same second, which is why it feels like one step from the outside.\n\nHere's the full path from a `.py` file to actual output on your screen.\n\n\n```mermaid\nflowchart LR\n SRC[checkout.py
Source code]:::primary\n LEX[Lexer + Parser]:::orange\n AST[AST
Syntax tree]:::teal\n COMP[Compiler]:::orange\n BC[Bytecode
.pyc cached]:::secondary\n PVM[PVM
Stack machine]:::green\n OUT[Output]:::red\n\n SRC --> LEX --> AST --> COMP --> BC --> PVM --> OUT\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe first four boxes (source through bytecode) are the compilation stage. The PVM box is the runtime. There's no separate build command like `javac` or `gcc`. When you run `python checkout.py`, the `python` executable does both jobs back to back: compile first, then execute.\n\nWe'll walk each stage using a tiny example.\n\n\n```python\ndef cart_total(price, quantity):\n return price * quantity\n\nprint(cart_total(19.99, 3))\n```\n\n\nThat output is the end of the pipeline. Let's start at the beginning.\n\n---\n\n# Source to Bytecode\n\nWhen you run `python checkout.py`, the interpreter does three things before any of your code starts running:\n\n1. **Lex and parse.** The lexer breaks the source text into tokens (`def`, `cart_total`, `(`, `price`, etc.), and the parser arranges those tokens into an Abstract Syntax Tree (AST). The AST is a tree of nodes that represent the structure of your program: a function definition contains parameters and a body, the body contains a return statement, the return statement contains a multiplication expression.\n2. **Compile.** A compiler walks the AST and emits **bytecode**, a compact instruction set for the Python Virtual Machine. Each instruction is one or two bytes (which is where \"bytecode\" gets its name), and the instructions describe operations like \"load a local variable\", \"multiply the top two values on the stack\", or \"return\".\n3. **Hand off.** The bytecode is given to the PVM, which executes it.\n\nThe important point: this isn't machine code. The CPU sitting in your laptop has no idea what `BINARY_OP` means. Bytecode targets an abstract machine, and the PVM is the program that makes that abstract machine real.\n\nThis is why calling Python \"interpreted\" is half the truth. Your source code is **compiled** to bytecode first. Only the bytecode is then interpreted by the PVM. So Python is more accurately described as \"compiled to bytecode, then run on a virtual machine.\"\n\n---\n\n# The .pyc Cache (`__pycache__`)\n\nIf Python recompiles your source every time you run it, that's wasted work. Most of the time the source hasn't changed since the last run. Python avoids the redundant work by caching the compiled bytecode on disk.\n\nThe cache lives in a folder named `__pycache__`, created next to your `.py` files. Inside it, you'll find files like:\n\n\n```shell\ncart_utils.cpython-311.pyc\norder_status.cpython-312.pyc\n```\n\n\nThe naming pattern is `{module}.{implementation}-{version}.pyc`. The implementation tag (`cpython`) and version (`311`, `312`) keep caches from different Python builds isolated, so a `.pyc` compiled by Python 3.11 won't accidentally be reused by Python 3.12.\n\nEach time Python imports a module, it checks whether a matching `.pyc` already exists and whether the source file has changed since that `.pyc` was written. If the cache is fresh, Python skips the parse and compile steps and loads the bytecode directly. If the source has been edited, Python recompiles and updates the `.pyc`.\n\nA few practical points worth knowing:\n\n- `__pycache__` is created automatically. You don't manage it.\n- It's safe to delete. Python will rebuild it on the next run.\n- Most projects add `__pycache__/` and `*.pyc` to `.gitignore`. The cache is a build artifact, not source.\n- Scripts you run directly (like `python checkout.py`) usually don't get cached. The cache mainly helps imported modules, since those are what get reused across runs.\n\n\n> **INFO**\n>\n> **Cost:** Cold-starting a large Python application can take noticeably longer the first time because every imported module gets parsed and compiled. Subsequent runs are faster because `__pycache__` already holds the bytecode.\n\n\n---\n\n# The Python Virtual Machine\n\nThe Python Virtual Machine is the program that actually runs your bytecode. It's a **stack-based** virtual machine, which means most of its instructions push values onto an evaluation stack, pop values off, and push results back.\n\nTo make that concrete, consider what `price * quantity` looks like to the PVM:\n\n1. Load `price` onto the stack.\n2. Load `quantity` onto the stack.\n3. Pop both, multiply them, push the result back.\n4. Pop the result and return it.\n\nThat's it. No registers, no memory addressing. Every operation flows through the stack. This design keeps the bytecode small and simple to interpret, at the cost of running slower per operation than register-based machine code on a real CPU.\n\nThe PVM is implemented as a giant loop in C (the actual loop lives in CPython's `ceval.c`). The loop reads one bytecode instruction, dispatches to the C function that implements it, and moves on to the next instruction. That loop is the engine running every Python program in the world.\n\nOne implication is that \"Python is slow on CPU-bound work\" is partly a comment on this design. The PVM does much more work per instruction than a CPU does for a native instruction. Languages with a Just-In-Time compiler (like PyPy) can sidestep this by translating hot bytecode to native code at runtime, similar to how the JVM works. Standard CPython doesn't do that, which is why CPU-heavy Python code often hands off the actual computation to C libraries like NumPy.\n\n---\n\n# Seeing the Bytecode\n\nYou don't have to take the existence of bytecode on faith. Python ships a module called `dis` (\"disassemble\") that shows you the bytecode for any function.\n\n\n```python\nimport dis\n\ndef cart_total(price, quantity):\n return price * quantity\n\ndis.dis(cart_total)\n```\n\n\nA few instructions are worth pointing out:\n\n- `LOAD_FAST` pushes a local variable onto the stack. `LOAD_FAST 0 (price)` pushes the first parameter; `LOAD_FAST 1 (quantity)` pushes the second.\n- `BINARY_OP 5 (*)` pops the top two stack values, multiplies them, and pushes the product back. The `5` is the internal opcode for multiplication.\n- `RETURN_VALUE` pops the top of the stack and returns it to the caller.\n\nThe exact opcodes and numbering shift between Python versions. Python 3.11 introduced `RESUME` and consolidated arithmetic operations under `BINARY_OP`. Older versions had separate `BINARY_MULTIPLY`, `BINARY_ADD`, and so on. Don't memorize the instruction set. The point is that the PVM is reading a real, inspectable program, not your Python source.\n\nThe `dis` module is genuinely useful when you want to understand why two pieces of code that look the same have different performance, or what a comprehension actually compiles to.\n\n---\n\n# Python Implementations\n\n\"Python\" is a language specification. Many programs implement that specification, and they all run Python code, but they do it differently under the hood.\n\n\n```mermaid\nflowchart LR\n SPEC[Python
language]:::primary\n CPY[CPython
Reference, C]:::orange\n PYPY[PyPy
JIT compiler]:::green\n JYTH[Jython
Runs on JVM]:::teal\n IRON[IronPython
.NET CLR]:::secondary\n MICRO[MicroPython
Embedded]:::red\n\n SPEC --> CPY\n SPEC --> PYPY\n SPEC --> JYTH\n SPEC --> IRON\n SPEC --> MICRO\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nHere's what each one is for:\n\n\n| Implementation | Written In | Best For | Notes |\n|---|---|---|---|\n| **CPython** | C | Almost everything | The reference implementation. What you download from python.org. When people say \"Python\", this is what they mean by default. |\n| **PyPy** | RPython | CPU-bound Python that runs for a while | Includes a Just-In-Time compiler that converts hot bytecode to native machine code. Often several times faster than CPython on long-running numerical or algorithmic code. |\n| **Jython** | Java | Embedding Python inside Java applications, scripting on the JVM | Compiles Python to JVM bytecode and runs it inside the Java Virtual Machine. Lets Python code call Java libraries directly. |\n| **IronPython** | C# | Running Python on the .NET runtime | Targets the .NET Common Language Runtime. Useful when you need Python to integrate with C# code. |\n| **MicroPython** | C | Microcontrollers, embedded systems | A small Python that fits on devices with kilobytes of RAM (Raspberry Pi Pico, ESP32, etc.). Implements a subset of the standard library. |\n\n\nFor 99% of work (web apps, scripts, data processing, machine learning, scripting), you'll use CPython without thinking about it. PyPy is the most common alternative people reach for when CPython is the bottleneck on a workload that can't be moved into a C library. The others matter mostly when you're crossing a platform boundary, like running Python inside a Java server or on a microcontroller.\n\nOne thing to keep straight: when this chapter talks about \"the PVM\" and \"bytecode\", it specifically means CPython's PVM and CPython's bytecode. PyPy has its own intermediate representation, Jython compiles to JVM bytecode, and so on. The user-facing language is the same, but the internals are entirely different runtimes.\n\n---\n\n# The GIL in One Paragraph\n\nCPython has a piece of internal machinery called the **Global Interpreter Lock**, or GIL. It's a mutex that allows only one thread to execute Python bytecode at a time, even if your machine has multiple CPU cores. The GIL exists to keep CPython's memory management simple and fast for single-threaded code, but it means that multi-threaded CPython programs do not get true parallel execution for CPU-bound work. Workarounds include using `multiprocessing` instead of threads, calling into C extensions (like NumPy) that release the GIL, or switching to a GIL-free implementation. Note that PyPy also has a GIL; Jython and IronPython do not, because they rely on their host runtime's threading model.\n\n---\n\n# Memory and Garbage Collection in One Paragraph\n\nYou never call `free` or `delete` in Python. The runtime tracks how many references point to each object, and when that count drops to zero, the object is freed immediately. This is called **reference counting**, and it handles the vast majority of cleanup in CPython. Reference counting alone can't break circular references (object A holds a reference to B, B holds a reference to A, nothing else points to either), so CPython also runs a periodic **cyclic garbage collector** that finds and reclaims those cycles. You can interact with it through the `gc` module, but you usually don't need to.\n\n---\n\n# Quiz","pageType":"python"}

Get Premium