1. The Extended Python Debugger

The extended Python debugger builds on work done in the standard Python Debugger (pdb.py).

On not inventing yet another interface:
In extending the command set and functionality, we've used the GNU debugger (gdb) as a guide for many reasons.

First the command set is likely to be complete, given its longevity. Also, because of its longevity and pervasiveness, it is likely to be more helpful to users--especially those that know gdb or my GNU Bash debugger bashdb or to some extent my GNU Make debugger. All of these follow the same command interface and the learning curve is reduced for people familiar with one of these; they are less likely to get confused when switching between debuggers.

But it also has been helpful for other programs. I digress for a little history.

When I first thought about adding the bash debugger into the GUI interface ddd, basically all I had to do was tell ddd that handling this construct (e.g., stepping) is like gdb. There were a few places where I told ddd not to follow gdb but Perl instead because the paradigm was more like a scripting language than a compiled language. But in the end, adding support for the bash debugger inside ddd was much more straightforward and required much less thought than if I had invented my own debugger command set.

After this was done and I fired up ddd, I noticed that, when my cursor was hovering over some of the buttons, short descriptions for the command were given. Furthermore there was a button called ``customize bash'' added setting variables inside. But I hadn't added a box widget for customization or modified any code for using tool tips. How did ddd do this?

Because I had copied the output format of gdb's info, set and show commands, ddd ran these commands on its own and parsed the output; it then used that output to form tool tips and create customization boxes.

In responses to a preliminary posting to comp.lang.python asking why the Python debugger was different from other debuggers, a number of people indicated that it didn't matter since they did not use the standard Python debugger, or did not use it much. To some extent, I wonder if this is not a chicken-and-egg problem: is the debugger lacking in usefulness because people don't use it much or do people not use the debugger because it is lacking in usefulness?

I'm not sure, but if the standard Python debugger is little used, keeping compatibility is not important.

So, in cases where the standard Python debugger was incompatible with gdb, the gdb commands have been used.



Subsections
See About this document... for information on suggesting changes.