01Running Python

In Chapter 0 we built the machine down to the switch. In this chapter we make it run our code, and I want to go slowly. There's a question hiding in here that most tutorials walk straight past. Here's the plan. First we'll start the Python interpreter in interactive mode and watch it evaluate our lines one at a time. Then we'll drop those same lines into a .py file and run the whole thing at once. The whole way through, we keep asking the one thing that matters: what is CPython doing to your source in the moment before line 1 runs? By the end we've shipped the course's first real program: a two-song playlist that clears the terminal and prints Blinding Lights and Titanium from a single print() call, where we control every byte that hits the screen. None of it is magic. It's just the machine doing exactly what we tell it, once we actually know what we're telling it.

01A conversation with Python

Let's start with the smallest thing that runs. Open a terminal, type python, and hit Enter. Watch what it does. It prints a prompt — three angle brackets, >>> — and then it stops. It blocks: it's literally sitting there waiting on your input, on stdin, doing nothing else. Don't skip past that pause, because it's the whole point. Nothing has executed yet. It's just holding the door open. Now type an expression and press Enter. It evaluates the line right there and prints the result back — no compile step to run first, no build, no wait you can feel. You give it a line; it gives you an answer.

So give it a real one. We have two tracks queued for a set: "Blinding Lights" (200 seconds) and "Titanium" (245 seconds), the pair we'll carry through this whole book. And we have one thing we actually want to know: how long is the playlist? That's just the two durations added. Ask, and it answers before your finger is off the key:

>>> 200 + 245            # you type this; Python answers the next line
445
>>> print("Blinding Lights", "by", "The Weeknd")
Blinding Lights by The Weeknd
>>> "Titanium"              # a bare value — echoed back with quotes
'Titanium'
>>> _                     # the underscore remembers your last answer
'Titanium'
>>>

Look at what it just did that you never asked for. You typed 200 + 245 and it volunteered 445 — a seven-and-a-half-minute set. That number is worth a second glance. It has already outgrown Chapter 0's single byte, which dead-ends at 255. Two durations that each fit in one 8-bit box add up to one that no longer does. You never said "show me," yet the answer appeared. That back-and-forth has a name: the REPL, for read-evaluate-print-loop. The name is just a to-do list of what it does to every line. It Reads the raw characters, Evaluates them (boils the expression down to a single value), Prints that value back as a courtesy, then Loops around and reopens the prompt. Under the hood each line is quietly compiled to bytecode — the compact instruction list we'll build by hand in section 4 — then run, then forgotten. And "forgotten" is exact. RAM is volatile — that was Chapter 0 — so this whole conversation lives only as long as the window does.

The echo was Python's idea. Next you take the microphone yourself — print(), and the one underrated comma that quietly types a space between your words. →

02print() — and the comma that types a space

You have already seen print() flash by. Now meet it properly, because it is the first real function you command, and it hides more cleverness than anyone bothers to mention. A function is a named action. You fire it by writing its name and then a pair of parentheses, and you drop whatever it should work on inside them. Hand print() a single thing and it shows that thing. Hand it several, separated by commas, and it shows them left to right, with exactly one space wedged between each — a space you never typed. Stranger still, the things need not match. A run of text and a bare number ride the same line without a word of complaint.

Run these four lines and watch print() give up its rules. The third line repairs the second, and the fourth snaps a line in half from the inside.

>>> print("Blinding Lights", 200)
Blinding Lights 200
>>> print("Blinding Lights" + 200)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate str (not "int") to str
>>> print("Blinding Lights" + str(200))
Blinding Lights200
>>> print("Blinding\nLights")
Blinding
Lights

Walk the four lines slowly, because two of them look alike and behave nothing alike. Line 1 uses commas and prints Blinding Lights 200, free space included. Line 2 swaps the comma for +, and + is a different tool entirely. Between two pieces of text, + means glue: weld them edge to edge, no space, no gap. But here is what the traceback is really objecting to. The number 200 and the text "200" are not the same kind of thing. One is a value the machine does arithmetic on — chapter 0's byte, a quantity. The other is three separate characters, the codes 50 48 48, that merely look like a number to you. + won't bridge two kinds, so it quits with a traceback. (Python calls these kinds types, and you'll pry them open in chapter 2. For now just hold the line between number and text.) Line 3 is the cure. str(200) manufactures the three-character text "200" out of the number, so now both sides are text and + welds happily: Blinding Lights200, no space, because glue adds nothing of its own. Line 4 shows the last trick: \n is a single character — the newline — smuggled inside the text to break the line by hand.

So here is the reveal the heading half-lied about. The comma is not glue, and it does not really "type a space." The comma just hands print() its items as separate deliveries. print then does three quiet things. It runs str() on each delivery so anything can be shown. It slips a separator between neighbours (its sep setting, default a single space). And it stamps one closing character after the last (its end setting, default \n, the newline). The space you never typed is sep. The line break after every print is end. Change them and the comma stays exactly where it is; only the spacing moves.

Type a line at the prompt and it works once, then dies with the window. To make Python perform the same lines tomorrow, and the day after that, the lines need a home on disk — a file it reads top to bottom. Scripts: lines that live on disk →

03Scripts: lines that live on disk

The REPL is a brilliant place to think, but it forgets everything the moment you close the window. Every line you typed is gone, unrecoverable, as if the conversation never happened. A script is the cure. You type your lines into any text editor and save the file as playlist.py, and now those lines are plain characters on a disk — a document that survives being closed, emailed, run tomorrow, run a thousand times. Nothing about the file is magic. Open it in Notepad and you would see exactly what you typed. It is 306 ordinary bytes of text, no more special than a shopping list. The .py on the end is just a label that tells your editor and the people who read it to treat the file as Python source.

To run it, you leave the conversation and speak to the operating system instead. Scripts are launched from the terminal's own prompt — the one that looks like C:\Users\you> — not from inside the REPL. This trips up everyone once. The REPL speaks Python, the terminal speaks commands, and python playlist.py is a command, not Python. So if you still see >>> staring back at you, you are in the wrong room. Type exit() to step out to the terminal first. Then, and only then:

C:\Users\you> python playlist.py

# playlist.py — a document that outlives the window it was typed in
# a comment runs from '#' to the end of the line; Python skips it entirely

print("MY PLAYLIST")            # a comment can ride on the same line as code
200 + 64                        # computed in a blink... then silently thrown away
print("Blinding Lights", 200)  # print() is the only thing that reaches the screen

Two things change the instant your code moves from the prompt into a file. First, the echo is gone. In the REPL, typing 200 + 64 printed 264 back at you as a favour. Run the same line in a script and the machine still computes 264, then drops it on the floor without a word. A bare expression in a file is a calculation nobody asked to see. From here on, anything you want on screen has to travel through print(). There is no free echo. Second, you gain comments. Everything from a # to the end of that line is invisible to Python. It is a note left for the only person guaranteed to be baffled by this file later: future you. And notice how print("Blinding Lights", 200) handles the comma. It prints Blinding Lights 200, sliding a single space between the two values for you.

Now, how does a saved file actually run? The plain answer — true 95% of the time, and we will sharpen it in a moment — is strictly top to bottom, one line at a time. Line 1, then line 2, then line 3, like a finger dragged down the page. This has a consequence that surprises beginners. If line 4 attempts the impossible, lines 1–3 have already run and their output is already on the screen, permanently. Everything from line 4 onward simply never happens. The program does not rewind. Drag the slider and watch a real run walk straight into a wall:

Here is where the tidy story bends. I told you a script runs strictly top to bottom, one line at a time, and that is a labelled simplification — true enough to reason with, but not the whole truth. Try this. Take a perfectly good file whose first four lines are ordinary print() calls, and put a single typo on line 5. Run it. You might expect the first four lines to print and then Python to choke on line 5. That is not what happens. Nothing prints at all.

So there are really two different moments a program can fail, and they feel completely different. A TypeError like the one in the slider is a runtime failure. The grammar was fine, so Python happily ran lines 1–3, and only tripped when it actually tried to add a word to a number. A SyntaxError from a stray typo is an earlier failure. The sentence didn't parse, so Python rejected the file wholesale before running anything. One lets three lines print; the other lets zero. That gap is your first glimpse of a hidden stage sitting between "save" and "run."

So in the sliver of time between your Enter keypress and the first character of output, Python quietly read the entire file and turned it into something else — the bytecode it actually runs. What is that translation, and where does the translated version go? →

04The hidden compile step

Type python playlist.py and press Enter. It feels like the machine simply starts reading your file, top to bottom, doing each line as it meets it. It doesn't. Two separate things happen, in order. First, CPython reads the entire file and compiles it. It translates your letters and spaces into bytecode: a compact list of tiny instructions, each labelled by an operation code that fits in a single byte. That's where the name comes from — the whole program becomes a string of bytes. Second, a thing called the Python Virtual Machine — a CPU built out of software, living inside the python program — runs that bytecode. And "runs" is a real, nameable loop: the same fetch-decode-execute cycle chapter 0 gave your silicon CPU. The PVM keeps an instruction pointer marking the next opcode. It reads that one byte (fetch), jumps to the handler for that opcode (decode), does what the handler says (execute), then nudges the pointer forward and goes round again. One byte, one jump, repeat — thousands of times a second. Your real silicon CPU never lays eyes on your source code. It runs the PVM, and the PVM runs your bytecode. This is chapter 0's translation ladder caught in the act: the middle rung, made of software instead of metal.

That bytecode is built fresh in RAM and thrown away the instant your program ends, with one thrifty exception. Any file you import gets its bytecode written to disk as a .pyc file inside a __pycache__ folder, tagged with the exact interpreter that made it (on this machine, cpython-312). On the next run, if the source hasn't changed, CPython skips the compile step for that file and loads the cached bytecode straight off the disk. Your top-level script — the one you named on the command line — is compiled every single time. It's the imports, the libraries you lean on again and again, that earn the cache.

Every handler needs somewhere to put the values it works on, and here the PVM makes a deliberate choice worth understanding. Think about what print("Blinding Lights", 200) demands. print and its two arguments must be sitting ready, in order, the instant CALL fires. And CALL has to grab exactly those and nothing else, even when an argument is itself an expression leaving its own half-finished results lying around. The cheapest structure that guarantees "the things I need are the ones most recently produced" is a stack: a scratch pad you only ever add to, or take from, the top — last in, first out (LIFO, the discipline chapter 0 named). That is why the PVM is a stack machine. LOAD instructions push a value onto the top. CALL pops its arguments and the function back off the top, does the work, and pushes the single result. No value ever needs a name; its position on the stack is its name. Step through the one line below and watch the software CPU do exactly that, one tiny instruction at a time.

Those are two genuinely different failures, at two different moments, and you can feel the seam between compile and run by triggering each one. A broken quote never produces a single line of output, because compilation fails before the PVM starts. A type mismatch prints everything above it first, because the PVM was already happily running right up until it hit the impossible line.

import dis
dis.dis('print("Blinding Lights", 200)')
# RESUME            0            ← interpreter housekeeping
# PUSH_NULL                      ← calling-convention setup
# LOAD_NAME         print        ← look up the name "print"
# LOAD_CONST        'Blinding Lights'
# LOAD_CONST        200
# CALL              2            ← call it with 2 arguments
# RETURN_VALUE

code = compile('print("Blinding Lights", 200)', 'demo', 'exec')
type(code.co_code)   # <class 'bytes'> — literally a bytes object
len(code.co_code)    # 22 — that one line is 22 bytes of instructions

The PVM will happily run your bytecode all day — but it cannot clear your terminal, open a file, or reach the network on its own. Those powers belong to a bigger authority the PVM has to politely ask. Time to meet it. →

05Borrowing the operating system

Here is a humbling truth about the program you are about to write: it owns almost nothing. The screen, the files on your disk, the other windows, the network card — none of it belongs to your code. It all belongs to the operating system, chapter 0's tireless manager, the one that hands out RAM and keeps the ledger. So picture your terminal after you've printed your whole playlist: "Blinding Lights" — 200 s, "Titanium" — 245 s, and a dozen lines of trial and error above them. You want a clean slate. And you discover Python cannot simply wipe the screen. It has no hands. What it can do is ask. It sends a polite request up to the manager and lets the manager do the deed.

That request has a name. The shell is the program already living inside your terminal window: the thing that reads each line you type and gets the OS to carry it out. When Python hands that same shell a command from inside your program, exactly as if you'd typed it yourself, we call the move shelling out. The tool for it is one function: os.system().

>>> import os
>>> os.system('cls')        # ask the shell to wipe the terminal (Windows)
0
>>> os.system('notepad')    # ask it to open Notepad — Python blocks until you close it
0

Four ideas are packed into that first line, so let's unpack them one at a time. os is a module: a ready-made toolbox of code you bring into your program with import. You don't write it, you borrow it. system is one tool inside that box, and the dot in os.system simply means look inside os and find system. When you call it, three things happen in a heartbeat. Python's thread blocks — it does not "freeze" by magic, it is parked in a wait, running no further instructions — while the OS spins up a subprocess (a brand-new little program of its own, created here by Windows' CreateProcess) to run your command string. When that subprocess ends, the OS reaps its exit status and hands that single number back to the parked thread, which now wakes and runs on. By near-universal agreement, 0 means "finished cleanly." That trailing 0 in the REPL isn't output from cls. It's the exit status coming home, and the REPL echoes it the way it echoes every value you hand it.

Before we watch the round trip, look at where your program actually sits. When you launched Python, the shell didn't absorb it. It spawned it, as a separate process with its own serial number. Your program is a citizen in a small family tree, and shelling out just adds one more child to it.

Now the round trip itself. It's not one instant but a little five-beat handshake, and Python is asleep for the middle three beats. Drag the step slider and watch a single os.system('cls') travel out to the shell and come back carrying its exit status.

That returned number is quietly more interesting than the story so far lets on, because 0 is only the happy case. Any other value means the command failed, and the exact value is a clue about how. Ask the shell for a command it can't find and it hands back a plain 1. Run a command engineered to fail with a particular code, and that same code rides home to you:

>>> os.system('blindinglights')   # no such command — the shell shrugs
1                              # non-zero = something went wrong
>>> os.system('exit 5')          # a command that fails on purpose with code 5
5                              # the exact failure code comes straight back

You've been collecting parts for two chapters — bits and bytes, RAM's numbered boxes, the REPL, comments, import, and now a way to reach out and borrow the whole operating system. Every piece is on the bench. Time to bolt them together into something that runs on its own: the first real program. →

06The first real program

Everything this chapter taught collapses into eleven lines you can run right now: that source is just text, that python reads it top to bottom, that a running program is a process and not a file. Open your editor, save this as my_playlist.py, drop into a terminal in that folder, and type python my_playlist.py. (On some systems the command is spelled python3 — same program, longer name.)

# my_playlist.py — the first real program
import os

# wipe the screen — 'cls' is Windows; use 'clear' on macOS/Linux
os.system("cls")

print("MY PLAYLIST")
print("===========")
print("Blinding Lights", "by The Weeknd —", 200, "seconds")
print("Titanium by David Guetta —", 245, "seconds")
print("\nThat's the whole list. For now.")

Run it and the screen blanks, then the playlist announces itself. Read it downward, because that is exactly how Python reads it. import os pulls in a toolbox that talks to your operating system. os.system("cls") hands the word cls to the OS's own shell to run — that's the Windows "clear screen" command, and the screen wipes clean. Then five print calls paint the list, each on its own fresh line, because every print quietly ends with a newline. Nothing here is magic; each line does one small, literal thing.

Now look hard at the two song lines, because they are doing the same job two different ways. In the first, the artist, the length 200, and the word "seconds" are three separate values handed to print, spaced apart by commas. In the second, the whole artist phrase is tucked inside one longer string, and only 245 and "seconds" ride along as extras. Both come out with clean, single spaces, because between the values you separate with commas, print drops in exactly one space for you. And that lone \n in the last line? It's a single character meaning "new line," so it buys a blank row before the sign-off without a second print.

That "glued into the line" is worth slowing down on, because it's the one genuinely new idea here and it's easy to misread. When you separate values with commas, you're not adding spaces yourself and you're not formatting anything. You're handing print a little pile of values and letting it lay them out. Slide through the call below and watch it assemble the line one argument at a time. The green markers are the spaces print inserts between arguments. The spaces already inside a string (like the one between by and The) are yours and were there all along.

One quiet asymmetry is left dangling. print happily seats "Blinding Lights" and 200 shoulder to shoulder — yet try to glue them yourself with + and Python recoils: TypeError: can only concatenate str (not "int") to str. print converts without a fuss; + refuses to guess. Python has quietly sorted your values into kinds — types — each with its own rules and even its own footprint in RAM: the number 200 fits in 28 bytes, while the text "Blinding Lights" needs 56. What are these kinds, what's inside their boxes, and why does one bend where the other won't? The next chapter, Values & types, pries them open. →