Python Debugger (pdb + debugpy)

Overview

Three tools, picked by situation:

Tool	When
breakpoint() + pdb	Local, interactive, simplest. Add breakpoint() in source, run, get REPL.
python -m pdb	Launch script under pdb with no source edits.
debugpy	Remote / headless / attach to running process. DAP, scriptable.

Start with breakpoint(). It's the cheapest thing that works.

When to Use

• A test fails and the traceback doesn't reveal why a value is wrong
• You need to step through a function and watch a collection mutate
• A long-running process misbehaves and you can't restart it
• Post-mortem: an exception fired and you want to inspect locals at crash site
• A subprocess is the actual bug site

Don't use for: things print() / logging.debug solve in under a minute, or things pytest -vv --tb=long --showlocals already reveals.

pdb Quick Reference

Inside any pdb prompt ((Pdb)):

Command	Action
h / h cmd	help
n	next line (step over)
s	step into
r	return from current function
c	continue
unt N	continue until line N
j N	jump to line N (same function only)
b N	set breakpoint at line N
b file:N	set breakpoint in another file
b func	set breakpoint at function
cl N	clear breakpoint N
l	list 11 lines around current
ll	list whole function
w / where	show call stack
u / d	move up/down stack frame
p expr	print expression
pp expr	pretty-print expression
a	print args of current function
args	same as a
display expr	watch expression (re-eval each step)
interact	drop into interactive Python REPL

Using breakpoint()

def process(data):
    result = transform(data)
    breakpoint()  # Execution pauses here, pdb REPL opens
    return result

Run normally:

python script.py
# Pauses at breakpoint(), (Pdb) prompt appears

Using python -m pdb (no source edits)

python -m pdb script.py
# Starts paused at first line

Post-mortem debugging

Drop into pdb at the exact exception site:

import pdb, traceback
try:
    main()
except Exception:
    traceback.print_exc()
    pdb.post_mortem()

Or:

python -m pdb -c continue script.py
# Runs until exception, then drops to pdb at the crash

debugpy (remote attach)

For long-running processes or headless debugging:

# Install
pip install debugpy

# Option 1: Launch with debugpy
python -m debugpy --listen 5678 --wait-for-client script.py

# Option 2: Inject into running code
import debugpy
debugpy.listen(5678)
print("Waiting for debugger on port 5678...")
debugpy.wait_for_client()

Attach from another terminal (DAP client):

# Using debugpy's CLI to set breakpoints + continue
python -m debugpy --connect localhost:5678 --set-breakpoint script.py:42

Or use any DAP-compatible editor (VS Code, Neovim) to attach to port 5678.

Common Debugging Patterns

Watch a variable change

# In pdb
(Pdb) display my_list
# Each step, pdb re-evaluates and shows the value if changed

Conditional breakpoint

# In source
breakpoint() if condition else None

# Or in pdb
(Pdb) b 42, x > 100  # Break at line 42 only when x > 100

Inspect a running subprocess

import debugpy
# In the subprocess code:
debugpy.listen(5679)
debugpy.wait_for_client()
# Parent can attach to port 5679

Pitfalls

• breakpoint() in production: remove before commit. Use breakpoint() only for local debugging.
• pdb + multiprocessing: child processes don't inherit the pdb prompt. Use debugpy for multi-process debugging.
• pdb + asyncio: pdb works but async stack traces can be confusing. Use w (where) to see the full async call stack.
• Windows + pdb: some pdb features work differently on Windows. python -m pdb is more reliable than breakpoint() in some Windows terminals.
• debugpy port conflicts: default port 5678 may be taken. Use --listen 5679.