Debugging: know your tools before you need them

Prints are fine. Real debugging is faster.

breakpoint() — the modern entry point

Since Python 3.7, breakpoint() drops you into pdb at that line:

def process(items):
    for it in items:
        breakpoint()   # program pauses here in your terminal
        ...

Env var PYTHONBREAKPOINT=ipdb.set_trace or =0 switches or disables globally.

pdb commands you actually need

• n next line (step over)
• s step into function
• c continue until next breakpoint
• l list source around here
• p x print a value
• pp d pretty-print
• w where (stack)
• u / d up / down the stack
• q quit

Post-mortem debugging

When something crashes in production logs, launch:

python -m pdb script.py

Or programmatically pdb.post_mortem() after catching.

Reading tracebacks

Bottom-up:

1. Last line = exception type + message.
2. Above = where the exception was raised (deepest frame).
3. Higher = who called them. Skip framework noise. Look for your file paths first.

Logging beats print for real projects

import logging
logging.basicConfig(level=logging.DEBUG, format="%(asctime)s %(levelname)s %(name)s: %(message)s")
log = logging.getLogger(__name__)
log.info("processing %d items", len(items))

• Levels: DEBUG, INFO, WARNING, ERROR, CRITICAL.
• Configurable per-module without touching call sites.
• Structured logs (extra={...}) → readable by log aggregators.

Try it

1. Fix the bug in the starter code (process shouldn't add negatives).
2. Add a logger and log a WARNING when a negative is skipped.