trepan3k, while its interface is modelled off of gdb, is a bit different than other debuggers. In particular, it understands a lot more about the lower-level bytecode, allowing it to do things that other Python debuggers can’t. For example, it can debug Python bytecode when the source code is unavailable or has been constructed at run-time, which occurs when you are running code from a web templating system like Jinja. It can be used in a reverse-engineering setting, where there is no source code available, only bytecode.

This debugger knows which lines, columns, or bytecode offsets exist in a module. So it can prevent you from trying to set a breakpoint at places that do not exist in the code, or allow you to specify which code offset to stop at when there are several possible code offsets associated with a line.

In this talk, I will describe the design of this debugger (and other Python debuggers). Knowing this, attendees will be able to understand the kinds of things that can and cannot be done, and how various features affect performance, so they can avoid debugger slowness or tediousness when stepping through code.

I am also proposing a workshop for those who want hands-on experience. However, this talk is aimed at giving a concise overview of the topic of debugging in general and using trepan3k in particular.

Note: In advance of giving a talk or workshop, the software to be demonstrated is updated; this adds new features and fixes bugs. The new features of the release are typically mentioned in the talk, including PEP 768: the zero-overhead external debugger interface introduced in Python 3.14.