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.