Intro

• Intro
• Features
• Out-of-Process Debugging
• Better stepping granularity
• Step Granularity
• Event Filtering and Tracing
• Byte-code Instruction Introspection
• Debugger Command Arguments can be Variables and Expressions
• Egg Installable
• Modularity
• Etc.

A rewrite of pydb from the ground up.

This code assumes Python in the version range of 2.5 up to and not including 3K. Use pydb for Python 2.5 and earlier.

The intention is that IDE frameworks like Eclipse, Aptana or Netbeans and alternative Python implementations should be able to use pieces of the debugger as they see fit.

The command API portion of the debugger is largely modeled on the GNU GDB model. A command-line interface (CLI) is provided.

See the Tutorial for how to use.

Features

There's a lot of cool stuff here that's not in pydb or pdb.

Out-of-Process Debugging

You can now debug your program in a different process or even a different computer on a different network!

Better stepping granularity

Sometimes you want small steps, and sometimes large stepping.

This fundamental issue is handled in a couple ways:

Step Granularity

There are now step event and next event commands with aliases to s+, s> and so on. The plus-suffixed commands force a different line on a subsequent stop, the dash-suffixed commands don't, ">" "<", and "!" suffixes specify "call", "return" and "exception" events respectively. And without a suffix you get the default set by set different.

Event Filtering and Tracing

By default the debugger stops at every event: call, return, line, exception, c-call, c-exception. If you just want to stop at line events (which is largely what you happens in pdb) you can. If however you just want to stop at calls and returns, that's possible too. Or pick some combination.

In conjunction with handling all events by default, the event status is shown when stopped. The reason for stopping is also available via info program.

Event Tracing of Calls and Returns

I'm not sure why this was not done before. Probably because of the lack of the ability to set and move by different granularities, tracing calls and returns lead to too many uninteresting stops (such as at the same place you just were at). Also, stopping on function definitions probably also added to this tedium.

Because we're really handling return events, we can show you the return value. (pdb has an "undocumented" retval command that doesn't seem to work.)

Byte-code Instruction Introspection

We do more in the way of looking at the byte codes to give better information. Through this we can provide:

• a skip command. It is like the jump command, but you don't have to deal with line numbers.
• disassembly of code fragments. You can now disassemble relative to the stack frames you are currently stopped at.
• Better interpretation of where you are when inside execfile or exec. (But really though this is probably a Python compiler misfeature.)
• Check that breakpoints are set only where they make sense.
• A more accurate determination of if you are at a function-defining def statement (because the caller instruction contains MAKE_FUNCTION.)

Debugger Command Arguments can be Variables and Expressions

Commands that take integer arguments like "up", "list" or "disassemble" allow you to use a Python expression which may include local or global variables that evaluates to an integer. This eliminates the need in gdb for special "dollar" debugger variables. (Note however because of shlex parsing expressions can't have embedded blanks.)

Egg Installable

Need I say more?

Modularity

The Debugger plays nice with other trace hooks. You can have several debugger objects.

Many of the things listed below doesn't directly effect end-users, but it does eventually by way of more robust and featureful code. And keeping developers happy is a good thing.(TM)

• Commands and subcommands are individual classes now, not methods in a class. This means they now have properties like the context in which they can be run, minimum abbreviation name or alias names. To add a new command you basically add a file in a directory.
• I/O is it's own layer. This simplifies interactive readline behavior from reading commands over a TCP socket.
• An interface is it's own layer. Local debugging, remote debugging, running debugger commands from a file (source) are different interfaces. This means, for example, that we are able to give better error reporting if a debugger command file has an error.
• more testable. Much more unit and functional tests. More of pydb's integration test will eventually be added.

Etc.

Of course, I think pydb has a number of cool things that are not in the stock Python debugger, pdb. See this for those features.