14The page you keep open

In Chapter 13 we taught Python what + should mean on objects of our own making. Thirteen chapters before that, all we had was a single bit. This last one isn't a lesson. It's the page you keep open after the lessons stop. Here's the plan. You get every value type on one honest line, every structure in one decision table, the fifteen idioms that carry most programs, and twenty-four words pinned down tight enough to kill eight myths that outlive most beginners. All the way through, we keep asking the one question that earns its keep: when you reach for a list, a dict, a generator, what are you really paying, and in what currency? By the end we fold all of it into six steps that turn the playlist into a working Playlist class — one that knows "Blinding Lights" (200s) sorts ahead of "Titanium" (245s). You walk out able to build without us, straight into Volume 2.

01Every value, one line each

Let's start by throwing almost everything away. Fourteen chapters, and the whole skeleton stands on just three facts. Hold these and you can re-derive the rest at a whiteboard. One: in CPython — the interpreter you're actually running — every value is a boxed object on the heap. Not the bare number 200, but a little parcel wrapped around it. First a reference count: how many names point at this box. It is kept for one blunt reason — the instant it drops to zero, the last name is gone, and CPython frees the box on the spot. Then a type pointer: what this thing is, and therefore what it can do. And only then the payload itself. Two: names are references. A name never holds the value. It holds the address of the box, the way a contact holds a phone number, not the person. Three: containers differ chiefly in how they find a thing. Mutability, and what's allowed to be a key, fall out behind that. And finding splits just two ways. The first is by computed position: list[i] is base + i×stride — one piece of address arithmetic, one probe, O(1), never a walk (exactly ch0's numbered boxes). The second is by hash: rather than scan slot after slot for a value you can't locate (O(n), unbearable at a million items), you fold the key down to a bucket number and jump straight there. Every other thing you learned — slicing, dunder methods, comprehensions, is versus == — is one of these three facts wearing a costume.

Here are the atomic values — the ones that aren't made of other values — each on a single honest line. Read the last column as a litmus test: the one experiment that pins the type down when your memory blanks.

Notice that these sizes aren't intuitive. The number 200 costs 28 bytes — fourteen times the two bytes its value alone would need — because you're paying for the box, not the digit. Line those boxes up smallest to largest and the whole space story of a computer fits on one rung-ladder.

The ladder hides the deepest of the three facts, so let's crack a box open. Whatever type you pick — a whole number, a song title, a whole playlist — the layout underneath is the same three-part parcel: a refcount, a type pointer, and a payload. Only two things change: the tag on the box, and the way you reach into the payload. Step the slider through all ten and watch that sameness hold.

Watch all three facts fall out of six lines. One object, two names, a mutation seen through both, and a hashability check that draws the container line:

import sys

song  = ["Blinding Lights", 200]   # a fresh object, born on the heap
alias = song                       # alias copies the reference, not the list

print(type(song), sys.getsizeof(song))   # <class 'list'> 72
print(song is alias, song == alias)      # True True — one box, so identical
alias.append("The Weeknd")               # poke it through alias…
print(song)                              # ['Blinding Lights', 200, 'The Weeknd']

print(hash((200, 245)))                  # a real int — a tuple is hashable, so key-able
hash([200, 245])                         # TypeError: unhashable type: 'list'

Values are the atoms. Every real program then asks the second question — list, dict, set, or tuple? One decision table answers it for good →

02The decision table

You have met all six now, one chapter at a time. Lined up shoulder to shoulder, they hand you a chooser that fits in a single breath. Need your songs in order and reachable by position? A list. A tiny record that must never change, and might itself become a key? A tuple. Want to look a value up by name, instantly, a million times an hour? A dict. Only ever asking "have I seen this before?" A set. Shoving and pulling at both ends of a queue? A deque. A flood of raw numbers where every byte is money? An array. Six questions, six answers. But the reason each answer is right lives in one table, and that table is worth carrying for the rest of your working life.

Here is what the table is really telling you: every row is a promise about time and space. A data structure is not a bag that holds your stuff. It is a bet about which single operation you will perform most, paid for in memory you don't get back. Find the row whose cheap column matches the move you'll make ten thousand times, and everything else falls into place. So let's read the table properly, cell by cell.

Reading rows is one skill. Choosing one under pressure is another. So drive the slider below through six real jobs off the playlist and watch the table collapse to a single lit answer each time. Notice how little of the row you actually consult. You look at the one column the job hammers, and the winner is obvious.

That trade is not hand-waving; you can weigh it. Build the exact same million integers four different ways, and watch the scale tip. Slide n from a thousand up to a million and the bars grow together. The one exception is the generator, which stays a sliver, because it never actually builds the million at all.

You can now pick a structure in five seconds flat. Next: thirteen chapters of hard-won habits, pressed into fifteen idioms you’ll type for the rest of your life →

03Fifteen idioms that carry most programs

An idiom is a decision someone already made well, frozen into a phrase. Not a trick, not clever code to show off. It's the opposite. It's the shortest way to say a thing so ordinary that the language grew a groove for it, and everyone who reads Python reads the groove at a glance. You could always write the long way round; an idiom is the community agreeing you shouldn't have to. Learn these fifteen and you'll recognise most of the everyday Python you'll ever meet, because most everyday Python is these fifteen, rearranged.

Here they are, running — on the playlist we've carried since page one, now four songs long so the loops have something to bite on:

playlist = [
    {"title": "Blinding Lights", "artist": "The Weeknd",           "seconds": 200},
    {"title": "Titanium",        "artist": "David Guetta ft. Sia", "seconds": 245},
    {"title": "One More Time",    "artist": "Daft Punk",           "seconds": 320},
    {"title": "Strobe",          "artist": "deadmau5",            "seconds": 634},
]

# a 1-based menu — no manual counter, no off-by-one
for n, song in enumerate(playlist, start=1):
    print(f"{n}. {song['title']} — {song['artist']}")

titles  = [s["title"] for s in playlist]                        # build a new list
short   = [s["title"] for s in playlist if s["seconds"] < 300]  # filter: the test rides AFTER the for
by_len  = sorted(playlist, key=lambda s: s["seconds"])          # new sorted list; playlist untouched
artists = {s["artist"] for s in playlist}                        # set comp — duplicates fall out for free
length  = dict(zip(titles, [s["seconds"] for s in playlist]))   # two parallel lists → one dict

with open("playlist.txt", "w") as f:                            # the file closes itself, even mid-crash
    for s in playlist:
        f.write(f"{s['title']}|{s['seconds']}\n")

Run that top to bottom and the menu prints 1. Blinding Lights — The Weeknd down to 4. Strobe — deadmau5. Then short comes out ['Blinding Lights', 'Titanium'], artists is a four-name set, and playlist.txt is written and closed. Not one i = 0, not one manual counter, not one f.close(). That absence is the idiom. Let's put the single richest line under a microscope — the comprehension — because once you can read one, you can read the family.

A diagram is frozen, though, and a comprehension is a verb. So run it by hand. Below, the recipe on the left is short from the code above — keep the title of every song under 300 seconds. Step the slider and watch Python do exactly what you'd do with a highlighter. It walks the list top to bottom, holds each song against the test, and drops the survivors into a brand-new list on the right. Nothing clever happens. That's the point.

That's one idiom read to the metal. Here are all fifteen on one card — the loops that count, the phrases that filter and glue, and the small guards that keep a program upright:

Idioms are your hands — the moves your fingers make without asking. Vocabulary is your mouth: twenty-four words defined in one line each, and eight stubborn myths worth leaving at the door before you go →

04Twenty-four words — and eight myths

Documentation stops being fog the day a handful of words snap into exact senses. Not synonyms, not vibes, but the single meaning this course leaned on, chapter after chapter, with no drift. Below are twenty-four of them. And here is the secret that makes them learnable: they are not twenty-four unrelated facts. They are twenty-four views of one object. Take the smallest real fact from the playlist we've carried since page one — "Blinding Lights" runs 200 seconds — and store it as secs = 200. That one int is enough to demonstrate almost every word in the list: what it is, where it lives, how Python finds it, and what happens when you try to change it.

So before the list, look at the object itself. Everything the vocabulary names is somewhere in this one picture — the box, the name pointing at it, the little header that makes it cost more than a bare number, and the properties (immutable, hashable) that decide what you're allowed to do with it.

Now the full list, grouped not alphabetically but by the mental model each word belongs to — the object first, then the containers, then when work happens, then functions and scope, then the machinery under classes. Read each line as the exact sense this course used.

The object model. An object is one chunk of the heap — a value plus the type stamped on it that says what the value can do; our 200 is an int object. It is boxed: the bare number rides beneath a type pointer and a reference count, which is why sys.getsizeof(200) reports 28 bytes, not one. A reference is a name — or a list slot, or a dict value — that stores the object's address, never the object itself. The refcount is CPython's cleanup meter: it tallies how many references aim at the object and frees it the instant that count hits zero. The garbage collector is the backup sweep for the one case refcounting can't catch — objects that reference each other in a cycle, propping both counts above zero forever. The small-int cache is a shortcut: CPython builds every integer from −5 to 256 once at start-up, so every 200 in your whole program is the same object (a = 200; b = 200; a is b is True). An object is immutable when it can never change — int, str, tuple; "editing" one silently builds a new object with a new id, so x = 200; x = x + 1 moves x to a different box. It is mutable when it changes in place and keeps its id — list, dict, set, the whiteboard you wipe and reuse. And it is hashable when it has a stable hash — hash(200) is 200 — which is exactly the ticket to be a dict key or a set member; immutables qualify, a list does not (hash([200, 245]) raises TypeError).

What the containers really are. A dynamic array is a single contiguous block that quietly over-allocates spare slots, then relocates itself to a bigger block when it outgrows them — that's what a list is, which is why indexing is instant yet the block occasionally has to move house. A hash table stores items in buckets addressed by hash(key), so a lookup jumps straight to the bucket instead of scanning — that's what dict and set are. Big-O is the shorthand for how cost grows as the data grows, constants thrown away: O(1) flat no matter the size, O(n) climbing in step with it, O(n²) the nested-loop trap you feel the moment n gets real.

When the work happens. Something is lazy when it computes each value on demand instead of up front — range(10**6) weighs the same 48 bytes as range(10) because it stores a rule, not a million numbers; eager, its opposite, builds everything now and pays now. A generator is the workhorse of laziness: a function frozen mid-run by yield, handing back one value each time you ask, remembering its place, spent once exhausted. A comprehension is a loop folded into one expression that builds a list, dict or set — [s for s in lengths if s > 210] — eager by default, its lazy cousin being the generator expression in round brackets.

Functions and where names live. Functions are first-class: a function is just another object, so you hand its name around with no parentheses — sorted(songs, key=len) passes len itself for Python to call later. Every call gets a stack frame — the scratch space pushed on for that one invocation, holding its local names, popped and forgotten the instant the call returns; frames pile on the stack while every object they point to lives out on the heap. When Python meets a bare name it resolves it by LEGB — Local, then Enclosing, then Global, then Built-in, first match wins. A closure is a function that keeps using names from the scope it was defined in, even after that scope has returned — the enclosing value rides along with it. And pass-by-object-reference is how arguments actually travel: a call binds the parameter to the very same object the caller holds, so mutating it is shared but rebinding the name is local — the fact that dissolves the whole "by value vs by reference" argument.

The machinery under classes. A dunder is a double-underscore method — __init__, __len__, __repr__ — that Python calls for you at fixed moments, so len(x) really runs x.__len__(). Name mangling is the class-body rule that rewrites any __name into _ClassName__name behind your back — a collision guard between parent and child, emphatically not a privacy lock. And the MRO, the method resolution order, is the fixed route Python walks up through parent classes to find a method — bool.__mro__ is (bool, int, object), so a method missing on bool is sought on int, then object, in exactly that order.

You've named the pieces and buried the myths. But a vocabulary you can recite still isn't a program that runs — so let's build one, end to end: six steps to the playlist app. →

05Build it: six steps to the playlist app

Reading built recognition: you nodded along, and the words made sense. Building is the other thing entirely. It builds recall, the ability to summon an idea onto a blank screen with nothing prompting you. This section is fourteen chapters folded into one program. Six exercises, each standing on the one before it, each naming the chapters it draws from. You start with three flat lists. By step six, the playlist you have carried since chapter 2 is a real, saving, sorting, class-based app — the same two songs the whole way, just wearing a heavier and heavier coat.

Here is the trick that makes the whole ladder cohere: one small fact — "Blinding Lights" runs 200 seconds — travels through every step, changing its shape but never its value. First it is an item in a list; then a slot in a tuple; then a value under a dictionary key; then an argument to a function; then a field in a line of a file; then an attribute on an object. Watch that single 200 follow you down the page.

Step 1 · Parallel lists — chapters 1, 2, 5. Three lists that line up by index: titles, artists, seconds, five songs long, anchored on "Blinding Lights" (200) and "Titanium" (245). Print a 1-based menu with enumerate(titles, start=1), then the total run time as m:ss using sum(seconds) with // 60 and % 60. Check: a single 200-second song formats as 3:20; the five-song total 1160 s prints 19:20.

Step 2 · Tuples and sorting — chapters 6, 10. Zip the three lists into rows: tracks = list(zip(titles, artists, seconds)). Loop with unpacking — for title, artist, secs in tracks: — then make a longest-first copy with sorted(tracks, key=lambda t: t[2], reverse=True) and pluck the single longest with max(tracks, key=lambda t: t[2]). Check: sorted hands back a brand-new list, so tracks[0] is still "Blinding Lights" — the original order is untouched.

Step 3 · Dicts and sets — chapter 7. Rebuild every track as a self-labelling record with a comprehension: [{"title": t, "artist": a, "seconds": s} for t, a, s in zip(...)]. Collect the unique artists into a set, then count songs per artist in a dict using the classic counts[artist] = counts.get(artist, 0) + 1. Check: add a second Avicii track and the set stays the same size while Avicii's count ticks from 1 to 2 — the two structures answer two different questions.

Step 4 · Functions and hardening — chapters 9, 13. Fold the moves into named tools: add_song(playlist, title, artist, seconds), total_seconds(playlist), songs_by(playlist, artist). Read new songs from input() and guard the seconds cast — try: secs = int(raw) / except ValueError: re-prompt. Check: typing abc where a number belongs must re-ask, never crash — an unguarded int("abc") raises ValueError and takes the whole app down with it.

Step 5 · A file that remembers — chapters 11, 13. save(playlist, path) writes one title|artist|seconds line per song inside with open(path, "w"); load(path) reads each line, split("|"), and casts the seconds back to int; wrap the read in try/except FileNotFoundError and return [] on a first run. Check: save, quit, rerun, load — and be sure the seconds compare equal as ints, not strings, or every later sort silently lies.

Step 6 · The class — chapters 11, 12. A Song class (or a @dataclass) with three attributes and a __repr__; a Playlist wrapping a list, exposing add(), total_seconds(), __len__ and __repr__ so len() and print() just work. Stretch: put __slots__ on Song and measure the per-instance size honestly (see the deeper cut), and make total_seconds a generator expression: sum(s.seconds for s in self.songs).

Drag the step control below and climb the staircase one rung at a time. Each step you reach lights gold; every step beneath it — already built, already reused — glows green. Read off the chapters it leans on and the exact check that tells you it works.

Step six has an exact finish line. Type this out and make it print, character for character — if it does, you have a class, a container, and two dunder methods all cooperating:

night = Playlist("Friday Night")
night.add(Song("Blinding Lights", "The Weeknd", 200))
night.add(Song("Titanium", "David Guetta", 245))

print(len(night))             # 2    — your __len__ at work
print(night.total_seconds())  # 445  — 200 + 245
print(night)                 # Playlist('Friday Night', 2 tracks, 7:25)

import sys
sys.getsizeof(plain)             # 48   — looks tiny...
sys.getsizeof(plain.__dict__)    # 272  — ...but it hauls THIS around too
hasattr(plain, "__dict__")     # True

sys.getsizeof(slotted)           # 56   — a heavier header, but...
hasattr(slotted, "__dict__")   # False — no per-instance dict at all

The app plays its last track and prints its tidy 7:25. So where do you point yourself next — what is worth learning after the language itself? →

06The road on

Here is an honest map, folded open one last time. Fourteen chapters back you met a bit and could not yet see how it held the number 200. Now you can follow that 200 — the length of "Blinding Lights", byte 0b11001000 — from the switch it rides on, through the box in RAM, up to the Python object and the name that points at it. This course installed the nouns of the language — int, str, list, dict, the frame, the heap, the reference. And, rarer than any tutorial bothers with, it showed you where each one lives in memory. What a book cannot hand you is mileage: the hundred small programs where the model stops being a diagram you recall and becomes a reflex you feel. You don't learn to drive by memorising the car. You learn by driving.

Part 2 exists for exactly that. Not more theory, but real programs, traced line by line, with the stack and the heap redrawn at every single step. A number-guessing game. A round of hangman. An email-slicer that pulls the name out of an address. You won't have to imagine the frame being pushed when a function is called, or the object appearing on the heap when a list is built. You'll watch it happen, one line at a time, and catch the exact instant a bug is born.

And Volume 2 — the working programmer — picks up on this exact spot and turns the model into shipped code, through six rooms. Step into each one below. Not one of them adds a new atom. A file is bytes leaving RAM for the disk. An import is one namespace borrowing another. A thread is frames taking turns on the same CPU. Every "advanced" topic is a rearrangement of things you already watched happen, which is why none of it needs more than what you now know.

Five doors lead out of this room. The trace walkthroughs open the hood for real — the guessing game line by line, every frame pushed and every object born on the heap at the exact moment it happens. Volume 2 — the working programmer begins where every run ends: the process dies and takes the playlist with it, and chapter 15 gives your data a life after the power cut. Volume 3 is the deep one — algorithms & complexity, where you learn to make code fast and think like the 1%. Volume 4 builds the thirteen containers your data lives in, from the bytes up. And the Algorithms Lab hands you the controls — race binary search against linear, sort an array by hand, watch a recursion tree explode. The map is finished. Pick a door and drive →