05Decide & repeat

In Chapter 4 we taught the machine to answer yes or no — comparisons, booleans, and the quiet rule that "" and 0 and every empty collection count as false. In this chapter we spend that answer. A program that only runs top to bottom, once, the same way every time, can't react and can't repeat. That's not a machine; it's a printout. So here's the plan. We give your code the two powers that close the gap: deciding — run this line or skip it depending on what's true right now — and repeating — run one line a thousand times without typing it twice. The whole way through, we keep asking the one thing that matters: what does the machine check, and the instant it has its answer, when does it stop checking? By the end you'll fold a whole playlist into a single running sum, count to a billion without ever storing a number, and walk two lists side by side in lockstep. Every one of those tricks falls straight out of the same yes/no you already built.

01A program that chooses: if / elif / else

Let's start with the smallest decision a program can make. Everything you've written so far marches straight down the page — line 1, line 2, line 3, no choices. But now you want the machine to treat a 200-second single differently from a ten-minute epic. For that you need a fork in the road. That fork is the if statement, and it's the smallest unit of intelligence code can have: ask a yes/no question, and run some lines only when the answer comes back yes.

Here's the part most people skate past: the question doesn't have to be a literal True. Chapter 4 gave you the real rule, truthiness, and if runs on exactly that. "", 0, None, and every empty collection ([], {}, set()) count as False; almost everything else counts as True. So if seconds > 180: works because the comparison hands back a real bool, and if title: works too — it quietly asks "is this string non-empty?" The block that runs is everything indented beneath the if line. This is chapter 2's third axiom finally cashing in: indentation is structure. Python has no curly braces and no begin/end. As it reads your file, its tokenizer measures the leading whitespace of each line and compares it against a stack of the blocks currently open. A line indented deeper than the one before opens a new block (the tokenizer emits an INDENT), and a line that steps back out closes one (a DEDENT). What the block needs is a consistent, deeper indent — any width works, so long as you keep it — and from that Python concludes: this line belongs to that question. Four spaces is simply the convention everyone settles on (it's what PEP 8 fixes), not a width the language enforces.

Three keywords braid into one structure. if asks first. elif (read it as "else, if") is asked only when everything above it has already failed. else is the catch-all for whatever fell through every gate. And here is the rule that separates people who think they know if from people who do: only the first matching branch runs. The instant one condition is truthy, Python runs its block and jumps past the entire rest of the chain. The conditions below are never evaluated, not even glanced at.

seconds = 200                 # "Blinding Lights", 200 s

if seconds > 600:
    label = "epic"
elif seconds > 180:
    label = "standard"        # <- this one runs
elif seconds > 0:
    label = "short"           # True too — but never reached
else:
    label = "empty?"

print(label)                  # standard

Look at that third gate. 200 > 0 is unmistakably True — 200 really is bigger than 0. And yet label never becomes "short", because Python found its answer one gate earlier at seconds > 180 and stopped there. The later truth is real, but it arrives too late to matter. That isn't a quirk; it's the whole point of a chain: the order of your gates is the order of your priorities.

Fig 01 froze the story at seconds = 200. Now take the slider yourself and watch the winning gate move. Push past 600 and "epic" lights up while the rest go dark. Drop to 90 and the win falls through to "short". Drag all the way to 0 and every gate fails, so else finally catches it. Notice what the greyed rows are telling you: below the winner, Python has already left, so those comparisons are never computed.

One structure, but it wears three shapes, and choosing the wrong one is the classic beginner bug. Nest an if inside another when the inner question only makes sense after the outer one passed. Chain with elif when you're sorting a single value into buckets and exactly one bucket should win — the length labels above. Write separate ifs when each check applies to everyone who got this far, independently. Picture a roller coaster. "Tall enough?" is the outer gate. "Child or adult ticket?" only matters once you're through it, so it's nested. "Want the ride photo?" applies to every rider regardless, so it's a sibling if standing on its own. Turn that last one into an elif and you've written a bug: riders who matched an earlier branch would silently skip the photo question.

seconds = 200
explicit = False

if seconds > 0:                 # outer gate: is this a real track?
    if seconds > 180:           # nested: only meaningful once it's real
        print("long — trim for radio?")
    else:
        print("fits a radio slot")

    if not explicit:            # sibling: fires for EVERY real track
        print("safe for the party playlist")

An if makes its choice exactly once, then it's spent. But a playlist isn't one song — it's five hundred, each needing the same verdict. You'd have to send the code back around to face the next one, and the next… which is precisely what a loop is for. →

02The for loop: do this for each one

You have a playlist and a question: how long does the whole thing run? You could add the five numbers by hand. But five could just as easily be five thousand, so what you really want is a way to say for each song, do the same small thing. That sentence is a for loop, and it is the single line of Python you will write more often than any other.

A for loop takes an iterable — anything that can hand out its items one at a time. A list hands out its elements; a string hands out its characters; a dict hands out its keys; an open file hands out its lines. The loop runs its indented block once for each item handed over, and one such pass is called an iteration. The name you write after for is the loop variable, and here is the part most people skim: it is a plain name, a label, not a box (chapter 3), that gets re-bound to the next item at the top of every turn. The loop copies nothing. It just re-points one label at each object that already exists, in order.

That bare skeleton turns useful the instant you pair it with the accumulator pattern: park a running total in a variable before the loop, then fold each item into it as you go. Start at zero, add each song's length, and when the loop runs dry, the total is your answer.

# seconds per song — "Blinding Lights" first, "Titanium" last
lengths = [200, 194, 247, 320, 245]

total = 0                  # the accumulator, starting empty
for seconds in lengths:    # bind, run block, repeat
    total += seconds       # runs 5 times

print(total)             # 1206
print(seconds)           # 245 — Titanium, still bound!

Run it and the last line ambushes everyone. seconds is still alive after the loop, still holding 245 — the length of the final song, Titanium. The loop variable is not sealed inside the block; when the loop ends, nobody wipes it. It stays bound to whatever it pointed at on the final turn. That's occasionally handy for debugging, and occasionally a trap. Reuse the name later assuming it's fresh, and you'll get a ghost from the last loop instead.

Watch the whole thing run. Drag the slider to advance one iteration at a time. Each step, the iterator hands over the next song, seconds re-binds, the block runs, and the green accumulator bar climbs toward 1206.

That "ask for the next one until it says stop" isn't a metaphor. It's the literal machinery, and Python will show it to you. A for loop is syntactic sugar: a convenient spelling for a plain while loop built on two functions. iter() turns your iterable into an iterator — a small object that remembers its place — and next() pulls the following item out of it. When the iterator is spent, next() raises StopIteration, and that exception is the loop's stop signal. You haven't formally met try/except or exceptions yet — the errors chapter builds them properly — so for now read the try/except in the desugaring below as one plain idea: ask for the next item; if what comes back is the stop-signal instead of a value, catch it and leave the loop.

# `for seconds in lengths:` is convenience spelling. Underneath:
it = iter(lengths)          # ask the iterable for an iterator
while True:
    try:
        seconds = next(it)  # hand over the next item
    except StopIteration:   # the iterator says "that's all"
        break               # ... so leave the loop
    total += seconds        # your loop body, unchanged

Summing a list you already have is one thing. But "do this 1,000,000 times" shouldn't mean building a million-element list first just to walk it — that's megabytes of RAM spent to hold numbers you'll throw away. range() is the trick: counting without ever storing the numbers. →

03range(): counting without storing the numbers

You have already met the loop that walks a playlist, taking each song in turn. But sometimes there is no list to walk — you just need to count. Print a banner five times. Number the tracks 1 through 5. Step through every one of the 200 seconds in "Blinding Lights". For all of that, Python hands you range(), and its trick is this: it lets you count to a million without ever holding a million numbers at once.

range(5) lays out the sequence 0, 1, 2, 3, 4 — five numbers, starting at zero and stopping before five. That last word trips up everyone exactly once: the stop value is exclusive, always. You don't get 5; you get everything up to it. Give range two numbers and the first becomes the start: range(1, 6) counts 1, 2, 3, 4, 5. Give it three and the last becomes the step, how far to jump each time: range(1, 11, 2) counts 1, 3, 5, 7, 9, striding two at a time and, as ever, halting before the stop. So there are three knobs: start, stop, step. That is the entire dial.

for track_no in range(1, 6):            # 1 2 3 4 5  — stop is exclusive
    print("now playing track", track_no)

for n in range(1, 11, 2):             # 1 3 5 7 9  — start, stop, step
    print(n)

Now the part that earns range its keep, and it is a story about memory, so it matters. A list of a million numbers is a million objects sitting in RAM, right now, all at once. A range is nothing of the sort. On the 64-bit CPython on my machine, sys.getsizeof(range(1_000_000)) reports 48 bytes, and sys.getsizeof(range(10)) reports the very same 48. The size doesn't budge, because the object only ever stores its three knobs; the numbers between them are never born until the loop reaches for them. The equivalent list, by contrast, weighs in at 8000056 bytes, about 8 MB, and that is only the row of slots. Each slot is an 8-byte arrow pointing at a separate integer object living elsewhere, so the real bill climbs higher still. (One honest caveat, so a later chapter doesn't quietly contradict this: CPython keeps the small integers -5 through 256 as shared singletons, so the first 257 arrows point at ints that already existed — but the other ~999,743 distinct values are freshly allocated heap objects. Either way, every one of them exists now.) This produce-on-demand strategy has a name: it is lazy.

Turn the knobs and watch the sequence appear beneath your finger. The dial below fixes the start at 0 and the stop at 20, and lets you change only the step. Notice two things as you drag. The lit numbers spread apart as the step grows, and the stop — that red 20 on the right — is never lit, no matter what. It is the fence you count up to but never touch.

import sys
print(sys.getsizeof(range(1_000_000)))          # 48       — three knobs, zero numbers
print(sys.getsizeof(range(10)))                 # 48       — the same tiny object
print(sys.getsizeof(list(range(1_000_000))))    # 8000056  — ~8 MB of slots alone

print(range(0, 100, 5)[3])                    # 15       — start + 3*step, no scan
print(999_999 in range(1_000_000))              # True     — arithmetic, not a search
print(list(range(10, 0, -1)))                 # [10, 9, ... 1] — a negative step counts down

Watch the laziness happen one turn at a time. Below, a loop runs over range(1, 6) — your five tracks. Drag the play-head and see what the machine actually does on each pass: it takes the recipe on the left (which never changes, and never grows past 48 bytes), does one multiply-and-add to compute the current number, plays it, and drops it. The numbers to the right of the head haven't been computed yet. They don't exist as anything but a promise, which is why they show up as question marks until the head reaches them.

A loop over range gives you each number; a loop over the playlist gives you each song. But what if you need the song and its position at once — or two parallel lists, titles and lengths, marched together in lockstep? →

04enumerate() and zip(): positions and parallel lists

The for loop you met earlier in this chapter walks a list item by item. But sometimes the item alone isn't enough — you want its position too. "Track 1, track 2, track 3…" The instinct, carried in from other languages, is to invent a counter and reach into the list by hand:

songs = ["Blinding Lights", "Titanium", "Levels"]

for i in range(len(songs)):
    print(i, songs[i])   # i is 0, 1, 2 — songs[i] fetches the item there

Those square brackets — songs[i] — mean "hand me the item sitting at position i," counting from 0, not 1 (chapter 6 unpacks indexing in full). It works. But look how much scaffolding it took: a counter you invented, the list's length, and an index back in. That's three moving parts to say one small thing. Python has a tool that says it in one. Hand enumerate your list and every turn it deals you a pair, an (index, value) tuple, which you unpack right there in the loop header. Want human track numbers that start at 1 instead of 0? Write enumerate(songs, start=1).

songs = ["Blinding Lights", "Titanium", "Levels"]

for n, title in enumerate(songs, start=1):
    print(n, title)
# 1 Blinding Lights
# 2 Titanium
# 3 Levels

Look closely at what lands in your loop each turn: not two separate things, but one tuple, (0, 'Blinding Lights'). A tuple is just a fixed little group of values held together in order — you'll build the type itself in chapter 6 — and writing n, title = (0, 'Blinding Lights') is tuple unpacking: Python splits the group open and binds each piece to a name, left to right. That is exactly what the loop header for n, title in … does on every turn: catch the pair, unpack it into n and title, run the body. The figure below shows the whole list unrolled into those pairs, with the default 0-based index in blue and the start=1 index in gold beside it.

enumerate solved "item plus its position." Its sibling zip solves a different everyday knot: parallel lists. Titles live in one list, artists in another, and the only thing tying "Titanium" to "David Guetta" is that they sit at the same position. zip(titles, artists) walks both lists at once and, every turn, hands you a single tuple with the matching pair — position 0 with position 0, 1 with 1 — like the two rows of teeth on a zipper meeting one pair at a time. Feed the result to dict() and those pairs become key–value entries.

titles  = ["Blinding Lights", "Titanium", "Levels"]        # 3 items
artists = ["The Weeknd", "David Guetta", "Avicii", "Daft Punk"]   # 4 — one extra

for title, artist in zip(titles, artists):
    print(title, "—", artist)
# Blinding Lights — The Weeknd
# Titanium — David Guetta
# Levels — Avicii          ← Daft Punk never appears: zip stopped at 3

print(dict(zip(titles, artists)))
# {'Blinding Lights': 'The Weeknd', 'Titanium': 'David Guetta', 'Levels': 'Avicii'}

Two behaviours are worth burning into memory. First, when the lists are different lengths, zip stops at the shorter one — silently, no error. The surplus teeth on the longer side simply never engage. Second, exactly like range, both tools are lazy: they manufacture each tuple only when the loop asks for it, and never hold a whole list of pairs in memory. Drag the zipper below and you can watch both facts happen at once.

list(zip(titles, artists, strict=True))
# ValueError: zip() argument 2 is longer than argument 1

from itertools import zip_longest
list(zip_longest(titles, artists, fillvalue="?"))
# [('Blinding Lights', 'The Weeknd'), ('Titanium', 'David Guetta'),
#  ('Levels', 'Avicii'), ('?', 'Daft Punk')]

Every loop so far has known its own length — the items run out, and it stops. But the most human loops don't: "keep asking until the password is valid," "keep simulating until the world settles." For those you can't count turns in advance; you loop while a condition holds — and it's on you to make sure the world eventually changes. →

05while: loop until the world changes

A for loop walks a collection you already hold. A while loop does something stranger and more powerful: before every single turn it re-asks a question, and it keeps going as long as the answer is truthy. That is the whole engine. Read the keyword literally as those three words: as long as the battery holds, as long as the queue has songs, as long as the user hasn't typed quit. The instant the answer comes back falsy, the body is skipped and your program flows on to whatever sits below the loop.

Two traps hide in that one sentence. First, the wording. Read while as until and you write the condition exactly inverted. That's the classic first while-loop bug, where the loop you meant to run "until the queue is empty" either never starts or never stops. Second, the world has to actually change: something in the body must nudge the condition toward falsy, or the answer stays truthy forever and you've built an infinite loop. When that happens, Ctrl+C is the emergency brake. And notice when the question gets asked: before the body, on every lap, including the very first. So if the condition is already falsy the moment the loop is reached, the body runs zero times. A while loop looks before it leaps.

Here it is on our playlist. The player has a little battery and a queue of songs, and it plays as long as there's charge left and a song still waiting:

queue = ["Blinding Lights", "Titanium", "Levels"]
battery = 5                      # percent

while battery > 0 and queue:     # "as long as", never "until"
    song = queue.pop(0)         # take the next song (lists: ch.6)
    battery -= 2
    print("playing", song, "| battery", battery)

# playing Blinding Lights | battery 3
# playing Titanium | battery 1
# playing Levels | battery -1

The condition leans on two tools from chapter 4 at once. A bare queue is an emptiness test — a non-empty list is truthy, an empty one falsy — and and short-circuits: if the left side is already false, the right side is never evaluated. Watch the third lap. It plays "Levels" and drags the battery down to -1. On the next turn Python checks battery > 0, gets False, and stops right there, never even looking at queue. The loop only ever exits at a check, never mid-body.

Both loops can hit a moment mid-turn where you think "we're done here" or "skip just this one." Two keywords cut a hole in the side of any loop — break and continue — and there's that else almost nobody knows about. →

06break, continue — and the else nobody knows

A plain for loop is obedient to a fault: hand it a playlist and it will walk every single song, top to bottom, no matter what it finds along the way. Real code is rarely that patient. Sometimes you want to stop the instant you've seen enough; sometimes you want to wave one item past and keep going. Those are the two escape hatches every loop hides: break and continue. Learn them and a loop stops being a fixed march and becomes something you steer.

break is the fire exit. The moment it runs, the loop is over: no more turns, no finishing the current body, execution simply reappears on the first line below the loop. continue is gentler — it abandons only this one turn. Picture a bouncer standing at the top of the loop body. continue turns the current item away at the door and calls in the next one, so every line below the bouncer only ever meets items that got past the check. Same loop, still running; you just skipped the rest of one lap.

Put a break together with a deliberately endless loop and you unlock Python's favourite "ask until it's right" shape. You can't know in advance how many times a user will mistype the input, so you write while True: — a loop with no natural end — and let a break be the one door out, opened only when the answer is finally valid:

while True:                      # deliberately endless — you can't know how many tries it takes
    reply = input("length in seconds? ")
    if reply.isdigit():
        seconds = int(reply)
        break                    # valid answer → step through the exit door
    print("whole seconds only — try again")

Without that break, while True would spin forever. With it, the loop runs exactly as many laps as it needs and not one more. Now watch both hatches work in the same loop: a scan across our playlist looking for one song, skipping anything too short to bother with:

playlist = [
    ("Blinding Lights", 200),
    ("Stay",            141),
    ("Titanium",        245),
    ("One More Time",   320),
]

target = "Titanium"
for title, seconds in playlist:
    if seconds < 180:
        continue              # too short to bother — skip to the next song
    if title == target:
        print("queued:", title)
        break                 # found it — stop scanning
else:
    print(target, "is not on this playlist")   # runs only if NO break fired

Trace it by hand. Blinding Lights (200 s) clears the length check and isn't the target, so the body just ends and the loop turns over. Stay (141 s) is under 180, so continue waves it past before the second if ever sees it. Titanium (245 s) clears the length check and matches, so Python prints queued: Titanium and break slams the exit. The loop prints exactly one line and stops. Run it and that's precisely what you get.

But look at that else hanging off the loop, not off an if. That is for-else, and it is the most misread punctuation in Python. The rule is simple once you rename it in your head: the else is the no-break clause. It runs only if the loop ran all the way to the end without ever hitting a break. Here a break fired, so the else is skipped and "is not on this playlist" never prints. Change target to a song that isn't there and the loop falls off the end untouched, so the else fires and announces the miss. It's the clean replacement for the clumsy found = False flag you'd otherwise juggle by hand.

One interactive to make the difference stick. Same playlist, but you set the cutoff — the shortest length you'll accept. Songs below it get turned away by continue. The first one that reaches it gets queued and breaks out. And if you push the cutoff above every song, nothing breaks and the else finally gets its moment.

You can now steer a loop — stop it, skip a lap, branch on how it ended. But every loop so far has walked a list you typed out by hand. Those lists have machinery of their own: how they grow, why append is instant while stuffing an item at the front is slow, and what a slice actually copies. That's next — Sequences: list & tuple. →