Two ways to see inside a running program
Both tools in this lesson answer the same question — what are the variables actually doing while this runs? — but they trade off differently, and picking the wrong one wastes real time. That is why professionals keep both within reach.
Print debugging is the checkpoint technique from lesson 7-3, and despite the sneering it gets, professionals use it daily. It shines when you want the history of values across a whole run, when code runs somewhere interactive tools cannot reach (a remote server, or the logs of a continuous integration run — lesson 6-3's CI robot, whose printed output is often all you get), and because it needs zero setup.
A debugger pauses a live program and lets you look around. In Python, drop breakpoint() on any line, run, and you land in pdb with commands like n (next line), s (step into a call), p expr (print any expression), and c (continue). It shines when you do not yet know what to print: you can inspect everything at the frozen moment, walk up the call stack, and poke at objects interactively.
Honest rule: know both. Prints answer "how did this value evolve?", the debugger answers "what on earth is the state right now?". Neither replaces the loop from lesson 7-1, they are just how experiments get run.
Code exercise · python
Run this watch-the-state-evolve session, the print flavor of what a debugger shows you stepping with n. One glance at the step lines reveals exactly when the balance goes negative.
Quiz
Which situation favors the debugger over print statements?
Code exercise · python
Your turn. running_max works on the first list but returns [0, 0, 0] for the all-negative one. Add a temporary step print inside the loop if you like, form the hypothesis, then fix the initialization so both lines match the expected output.
Problem
You add breakpoint() inside a loop and the program pauses there. Which single-letter pdb command runs just the next line so you can watch variables change line by line?