pdb.py - why is this debugger different from all other debuggers?

[rurpy at yahoo.com]

"R. Bernstein" <rocky at panix.com> wrote:
> Okay, a bit of an exaggeration.
>
> Recently, I've been using Python more seriously, and in using the
> debugger I think one of the first things I noticed was that there is
> no "restart" ("R" in perldb) or "run" (gdb) command.
>
> I was pleasantly pleased discover how easy though it was patch pdb.py
> and pdb.doc; my patch for this is here:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1393667&group_id=5470&atid=305470
...
> Well, so now we get to the second issue. Python's stack numbering is
> different from the way most (all?) other languages. And "up" and
> "down" in pdb.py follow the Python notion of direction rather than
> what is common among debuggers. Yes, I realize Python's stack
> numbering is the one true the right way; I have no doubt that Python
> programmers draw their trees with the root at the bottom. So at least
> for now I hacked in "frame -1" to mean what is generally called "frame
> 0" in other debuggers. And "frame 0" in my private hacked pdb.py goes
> to the most least-recently encountered entry or the grand-daddy place
> which calls all of the others.
>
> Finally, we come to listing breakpoints. Showing my gdb orientation,
> the first thing tried and looked for was "info break". Nope, not
> there. For a while I just thought one just couldn't list breakpoints
> and lived with that. Then when I decided I'll hack in an "info break"
> I realized that if you type "break" without any arguments it lists the
> breakpoints. (And yes, I see that the behavior is documented.)
...
> So what I am suggesting is that it would be helpful to just follow an
> existing debugger paradigm (or follow more closely) so folks don't
> have to learn yet another interface.

I was disappointed not to see any replies to this.
I use pdb a lot because most of my debugging needs
are simple, and I don't need/want the overhead or
complications of a heavy duty gui debugger.

I used ddd only little many many years ago, but
compatibility with existing tools I think is a big plus.
I would certainly consider using such a combination,
and even without ddd I think being behaving similarly
to existing tools is a "good thing".

I hope some of the other problems with it get
addressed some day:
- There is no way (I know of) to start a python script
  from the command line with the debugger active;
  I always have to modify the source to insert a
  pdb.set_trace().  I would like something like Perl's
  -d option.
- Exceptions often don't stop debugger in routine
  where they occurred; instead you are dumped
  into a higher (lower?) stack frame and have to
  navigate back to the frame the exception
  occurred in.
- It needs something like the Perl debugger's
  X command to display full information about
  an object (value and attributes).
- The help command is lame giving just a list
  of commands (which are often a single character)
  with no hint of what they do.