This is the debug-print I have been pasting into Python projects since around 2019. It prints to stderr so it never mixes with structured stdout, recurses one level at a time with two-space indentation, and bails out on cycles via an id() set. The two constants at the top, _MAX_ITEMS and _MAX_STR, are the part that matters most during real incidents: when a payload is 50k items deep, pprint will lock your terminal, but dprint shows the first five and a trailing count. I leave the file at ~/.local/lib/python/dprint.py and import sys; sys.path.insert(0, ...) it from a breakpoint() shell.

Webhook payloads from Stripe and similar services have deeply nested objects that turn print(event) into a wall of single-line JSON. I drop dprint into a handler, look at the structure, and zoom in on the path that matters (event['data']['object']['lines']). The depth-aware indent and 5-item truncation mean a 50-line list collapses to five lines plus ...45 more, which is what I want when I'm just trying to confirm the shape. (The accordion inlines dprint so it runs standalone in the playground; in real use I import it from the file in accordion 1.)

The trick that makes this stick is wiring dprint into builtins from a sitecustomize.py, so it is available without an import inside any breakpoint() or python -i. I gate it on try/except ImportError so a stripped-down container without my dotfiles still runs. The cost is one global name, which I have decided is worth it for a tool I reach for daily. If you are on a team where polluting builtins is frowned upon, drop this step and import dprint per-file instead.