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

[R. Bernstein]

Mike Meyer <mwm at mired.org> writes:
> But if I had to choose between being
> able to play with objects interactively or being able to step through
> code, I'll take the interactive interpreter every time.

Why would you have to choose?  You've created a straw-man argument.
No one has previously suggested *removing* tools or forcing one to use
one and not the other! The thrust that started this thread and the
intent was thoughts on *improving* debugging.

You say you are happy with what you have. Great! But then out of the
blue offer your non-help. And although that too wasn't the thrust of
the thread either (soliciting volunteers), it's not like you
apparently *had* been working on this either. Weird.

> Well, the tools I'm talking about here are ones that Python comes
> with. It may be simple-minded to assert that everyone who writes
> Python code uses the tools that come with Python, but it's not very
> bright to not use the tools that come with the language.

Not if one uses *better* tools. :-) Again in this very thread another
interpreter was mentioned which, alas, doesn't come with Python. But on
many systems it is installed rather easily. It addresses some things
that again in this thread have been noted as perhaps lacking in the
stock Python-supplied interpreter.

> I'm all to aware that not everyone writes code as easy to understand
> as what I do. 

(And it just may be that not everyone finds reading your code as easy
to understand as you think it is.)

> The correct solution for bad code was elucidated by
> Kernighan and Plauger nearly 30 years ago: "Don't fix bad
> code. Rewrite it." I don't do that nearly often enough.

I heartily agree. (But I also can't help note that this may be a little
bit of a self-serving statement.)

> A good debugger is a valuable thing, and I've used some incredible
> debuggers, including one that actually implemented DWIM.  Stepping
> through the code is one of the least valuable thing a debugger does,
> but it's also the thing that makes it a debugger. 

Hmmm. If that's really your view of what makes a debugger, I can see
why it's not all that important to you. But this could another one of
your exaggerate-to-make-absurd arguments.

Now that you mention it, stepping in pydb.py does have this little
thing that seems just a little different from the norm. When one steps
through a class or even a script with lots of methods/functions, the
debugger seems to stop at every def, which isn't all that
exciting. And say in contrast to gdb's step/next, you can't give a
count. (Perl allows one to enter an arbitrary expression to step/next
into). These do tend to make stepping less useful.

But as with the "restart" command that was mentioned at the beginning
of the thread, it wasn't all that hard to address in the current code
base.

> Pretty much
> everything else that a debugger does can be done by other tools. 

So tell me what tools you have to set a breakpoint somewhere in a
program possibly based on variable values, inspect arbitrary values as
you see fit and perhaps change them, and then either continue or
restart the program depending on how long it took to get to the point
and how messed up things were when you got there?  None of this
involves stepping, so by your definition it's something that doesn't
need a debugger.

> As
> those tools improve, the value of the debugger decreases. Python has
> very good other tools.

The argument also goes the other way. If one has a debugger that's
lacking -- and it looks to me that pdb.py is a little bit neglected
(in some cases I would even say not pythonic)-- then, sure, people are
going to try to find ways to avoid using it. This too was mentioned on
this thread.

Without a doubt Python has good tools. And no doubt they will continue
to improve as perhaps they should.  But I don't see this as an
argument for not to improving debugging in Python as well.