Inspect the Boundary in pdb

The case is stable now: quantity 4, threshold 4, an item that should be kept, an item that was dropped. You could squint at the comparison and probably guess the cause. The debugger offers something better than a guess: it stops the real run at the real line, with the real values sitting in front of you.

Start the program under Python’s built-in debugger:

python -m pdb catalog.py catalog.csv selected.json --minimum-quantity 4

You get a (Pdb) prompt instead of a result. The program is loaded but has not run yet.

Stop at the line that decides

You want to pause inside select_items, on the comparison that chooses whether an item is kept. Ask pdb to find it rather than counting lines yourself:

b select_items
c

b select_items breaks the next time that function is called. c continues until something stops it. Execution halts at the top of the function.

Now look at the source around you, and put a breakpoint on the comparison itself:

l

l lists the lines near where you are stopped, with an arrow marking the current one. Find the line holding item["quantity"] and note its number, then break there and continue:

b 42
c

Use whatever number l actually showed you. Line numbers depend on how you wrote the earlier chapters, so yours will not necessarily match anyone else’s.

Look before you step

You are now paused on the comparison, with one item in hand. Ask for the two values that decide its fate:

p item["quantity"]
p minimum_quantity

Both print 4. So this is the equality case, the one the option’s own help text promises to keep.

Now run just that line and see where you land:

n

n executes the current line and stops at the next one in this function. Watch where it goes: the append is skipped. The item with quantity 4 was dropped on a threshold of 4.

That is the whole diagnosis, and it is worth naming precisely, because a vague version of it leads to a vague repair. The comparison uses >, which excludes equality. The interface says “at least”, which includes it. One character of code disagrees with one word of the contract.

Leave the debugger with q.

Repair it, then confirm

Open catalog.py with nano, change that comparison from > to >=, save, and run the original command again:

python catalog.py catalog.csv selected.json --minimum-quantity 4
cat selected.json

It should now report two items, and selected.json should contain BK-101 and PN-330 in that order.

Be honest about what you just proved. You reproduced one case, found the expression responsible, and watched the fix change that case. You did not prove the rest of the program is correct, and you did not prove a future edit will not undo this. Those are real claims, and they need tests rather than a debugger. Chapter 10 is about writing them.

Take the instrument back out

A breakpoint is scaffolding. It belongs in an investigation, not in the file you hand to someone else.

If you experimented with breakpoint() or pdb.set_trace() inside catalog.py, remove it before you submit. Left in, it stops an ordinary user inside a debugger prompt they did not ask for and may not know how to leave.

Press Check my work once the repaired command and selected.json agree.

If the count is still wrong, run p minimum_quantity at the breakpoint again. Ask Monty to explain the difference between > and >= at a boundary if the equality case still feels slippery.