Reading a Program
Here is the skill that separates people who can read code from people who can only recognise it: tracing. Take a five-line program, become the machine, and track every box on paper — line by line, no skipping, no "yeah I get the idea". When a loop runs, you write the variables again EVERY lap. It feels slow, like sounding out words. It is also exactly how you will debug for the rest of your life, because bugs live in the gap between what you think a line does and what it actually does. This lesson is pure practice: watch the trace, then predict what each next line does to the boxes before it happens.
Be the machine
step 1 / 5Become the machine. One line at a time, and we keep the trace table honest.
The trace-table method
- One column per variable, one row per executed line. Evaluate the right-hand side completely BEFORE writing the assignment.
- On a loop: re-check the condition and write a fresh row every lap — no skipping, that is where bugs hide.
- On a function call: open a fresh mini-table for its locals; close it at return and write the returned value where the call was.
- Copy vs reference is THE trap: b = a copies the value for numbers/strings, but aliases the same object for lists/objects (both languages).
- Trace tiny inputs (n = 3) and the edges: empty, one element, duplicates, negative.
Debugging tools when tracing by hand gets old
- print(f"{i=} {total=}") — the = specifier prints name and value.
- breakpoint() drops you into pdb: n = next line, s = step into, c = continue, p x = print x.
- id(x) reveals aliasing: two names, same id → one object.
total = 0
for n in [3, 1, 4]:
if n % 2 == 1: # odd?
total += n
print(n, total) # trace line
# 3 3
# 1 4
# 4 4
print("final:", total) # final: 4a = 3; b = a; a = a + 1. Final values?
Trace it, then write it: sum_odds(nums) returns the sum of only the ODD numbers. For [3,1,4] that is 4 — exactly the program you traced.