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

[Mike Meyer]

rocky at panix.com (R. Bernstein) writes:
> Mike Meyer <mwm at mired.org> writes:
>> I don't use pdb a lot either - and I write a *lot* of Python. 
> Some of us may have to *read* a lot of python. (For example I know
> many people including myself who have had to deal with code written by
> consultants who wrote a *lot* of code but are no longer *maintaining*
> the code for various reasons). And one place debuggers tend to come in
> handy is in focused or problem-solving of others' code.

I also read a lot of Python. Cleaning up that which was created by
others is a common role for consultants.

>> If not, rather than load the application into a debugger
>> and futz with that, it's simpler to fire up the interpreter, import
>> the module that is misbehaving, instantiate and experiment on the
>> classes with bogus behavior. 
> If you have a good understanding of the code that may be a good thing.
> If you don't and debugging is easy (and I think someone else had
> suggested python may be in some circumstances lacking here), then
> debugging is desireable. I've noticed that different people pefer
> different things. And that's why there's race-track betting.

In my experience, a good way to gain an understanding of the code is
to play with it in the interpreter. Being able to feed arbitrary
things to methods and observe the results is invaluable. Being able to
step through the code line at a time also helps, and it's a good thing
that Python lets you do both. 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.

>> If you write code that consists of
>> reasonably small methods/functions, these tools work *very* well for
>> chasing down bugs. 
> It would be simple-minded to assert that everyone who writes python
> code works uses your tools or writes code as easy to understand as you
> imply your code is.

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.

I'm all to aware that not everyone writes code as easy to understand
as what I do. 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.

>> Given those two tools, I find I use pdb maybe once a year. I probably
>> wouldn't miss it if it vanished. 
> I guess you are in agreement with many POSIX shell (e.g bash, Bourne
> and Korn) developers.  You see, before I wrote a debugger for bash
> (http://bashdb.sourceforge.net) there just weren't any such
> things. :-) And those languages are very very old maybe 20 years or
> so.

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. Pretty much
everything else that a debugger does can be done by other tools. As
those tools improve, the value of the debugger decreases. Python has
very good other tools.


     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.