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

[R. Bernstein]

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

Encouraged, the next thing I noticed lacking from my usual debugging
repertoire was gdb's "frame" command which is the absolute-position
version of "up" and "down". Clearly since "up" and "down" are there,
adding a "frame" command is also pretty simple.

Perhaps I should explain that I noticed the lack of and wanted a
"frame" command because I had noticed that prior to adding "restart"
that when the program was restarted through a post-mortem dump, the
first line number in the post-mortem dump was not getting reported. So
Emacs was showing a weird position in the source; it was confusing and
not clear that a restart had actually taken place. When Emacs and the
debugger are out of sync, my usual way of fixing this is by issuing
"frame 0", which usually means go to the top (or is it bottom?) of the
stack which has a side effect of forcing emacs to update the display.

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.)

In fact the breakpoint-listing output looks similar to what gdb
uses. That's nice, but in both gdb and Perl's debugger a "break"
without an argument *sets* a breakpoint at the current the line, it
doesn't list it.

Here I'm in a little quandary as to what to do. My take would be to
just change the behavior of break so it works like the other debuggers
mentioned. In contrast to say the "frame" command, I fail to see how
pdb.py's lingo for "list breakpoints" superior. In fact it seems
inferior. If one wanted to extend the debugger command set to include
a "list information about breakpoint number n" (which gdb does by
"info break n"), I'm not sure this would fit in with the existing
lingo.

My guess is that pdb.py started as a small undertaking and grew
without all that much thought or concern as to what a full debugger
command set should or would be.

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.

Let me close with a rather pleasant experience when I tried something
like that in my debugger for Bash (http://bashdb.sourceforge.net). In
doing that I decided that I'd just try follow the gdb command set. Not
that I think gdb's is the most wonderful, orthogonal or well-designed
command set, but just that it is commonly used and rather
complete. For example, whereas pdb.py has "up" and "down", gdb's
version also allows a numeric argument to indicate how many places up
or down - again something pretty easy to hack in. No doubt someone at
some point found this useful, so it was added. And no doubt there are
programmers who use this. Might that not also apply to people
debugging Python programs? At any rate I wanted to reduce the learning
curve of folks using my debugger.

At some point someone asked for a GUI interface. I thought okay, and
found this GUI front-end called ddd. Naturally it handled gdb and Perl
as back ends. So to add in my bash debugger support, basically all I
had do do was tell ddd that handling this construct (say
"breakpoints") is like gdb. There were a few places where I told ddd
not to follow gdb but Perl instead because the paradigm needed had to
be more like a scripting language than a compiled language. But in the
end, adding support for bash inside ddd was much more straightforward
and required much less thought than if I had invented my own debugger
command set.

Well after this was done and I fire up ddd, I notice that when my
cursor is hovering over some of the buttons I see short descriptions
for what that command does. And there is this button called "customize
bash" and in that there are all these setting variables. But I don't
remember adding a box widget for customization or remember any code
that I modified using tool tips. How did it do this? I was very
curious and had to find out.

You see, because I even copied the output format of gdb's "info",
"set" and "show" commands, what ddd is doing is running these commands
on its own and parsing the output; it then uses that output to form
tool tips and create a customization boxes.

So of course when I recently added a debugger for GNU Make
(http://bashdb.soruceforge.net/remake) I've again followed this
principle. And again it's been helpful.

In sum, I think copying or following an existing command set might
also be a good thing to do in pdb.py.

 

[rurpy]

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.

 

[Fernando Perez]

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.

You may want to try out ipython (the current release candidate from
http://ipython.scipy.org/dist/testing/, which has many improvements on this
front). The %pdb magic will trigger automatic activation of pdb at any
uncaught exception, and '%run -d' will run your script under the control of
pdb, without any modifications to your source necessary.

- 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 pdb that ships with ipython is also modified to have tab completion, color
highlighting for listings and better stack handling than the default pdb.
With tab completion, it is trivial to explore an object dynamically (better
IMHO than dumping a potentially gigantic namespace on screen).

Regards,

f

 

[Mike Meyer]

Actually, you're not talking about changing the paradigm. You're
talking about minor tweaks to the command set.

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 don't use pdb a lot either - and I write a *lot* of Python. When
something goes wrong in Python, it tells you exactly what went wrong,
with which variable, and the file and line nubmer it went wrong at -
along with a backtrace telling you exactly how the code got
there. That's sufficient to track down most bugs you run into in
practice. 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 write code that consists of
reasonably small methods/functions, these tools work *very* well for
chasing down bugs. That my development environment lets me go from
editing the class to testing the new code in the interpreter in a few
keystrokes means it's *very* easy to deal with.

Given those two tools, I find I use pdb maybe once a year. I probably
wouldn't miss it if it vanished. I'm certainly not going to spend any
time working on it. Of course, if you're interested in extending it
- have fun.

<mike

 

[R. Bernstein]

You may want to try out ipython (the current release candidate from
http://ipython.scipy.org/dist/testing/, which has many improvements on this
front). The %pdb magic will trigger automatic activation of pdb at any
uncaught exception, and '%run -d' will run your script under the control of
pdb, without any modifications to your source necessary.

I really like ipython. Many thanks for writing it!

And, as you say, it does have many many useful improvements over
python's default interpreter shell, including the ability to call the
debugger minimal fuss.

But ipython it doesn't obviate the need for a better or more complete
or more one that more closely follows conventional debugger command
syntax.

 

[skip]

Mike> I don't use pdb a lot either - and I write a *lot* of Python.

Ditto. I frequently just insert prints or enable cgitb. Sometimes I enable
line tracing for a specific function and the functions it calls using a
tracing decorator. There are lots of things that are easier than breaking
down and learning how to use pdb. ;-)

Skip

 

[R. Bernstein]

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.

Thanks for your kind words and comments. As Fernando Perez mentioned,
one way to address the lack of a corresponding "perl -d" option is to
use ipython. And my current thought is that when one installs ddd it
will install a pdb command -- perhaps just make a symbolic link from
/usr/bin/pdb to the right place. So this may help a little -- even if
one doesn't *use* ddd.

As for the things that are not addressed by ipython, the above list of
desirable features is helpful . Adding an X command, extending the
help command to be say more like gdb's seems straight forward.

Adjusting the stack frame when an exception is not handled is probably
doable too.

 

[R. Bernstein]

(e-mail address removed) writes:
Actually, you're not talking about changing the paradigm. You're
talking about minor tweaks to the command set.

I am sorry if this was a bit of an exaggeration. Whatever.

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.

When
something goes wrong in Python, it tells you exactly what went wrong,
with which variable, and the file and line nubmer it went wrong at -
along with a backtrace telling you exactly how the code got
there. That's sufficient to track down most bugs you run into in
practice.

Sometimes the problem is not a bug which produces as backtrace. It
could be a misunderstanding of the intended behavior of the code.

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.

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.

That my development environment lets me go from
editing the class to testing the new code in the interpreter in a few
keystrokes means it's *very* easy to deal with.

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.

I'm certainly not going to spend any
time working on it.

Understood. I may have missed something here or wasn't clear - I
wasn't necessarily soliciting help for people to volunteer on this
although of course I would welcome any contributions. Are you the
author of pdb.py or a contributer to it?

Of course, if you're interested in extending it
- have fun.

Thanks!

 

[rurpy]

Mike> I don't use pdb a lot either - and I write a *lot* of Python.

Ditto. I frequently just insert prints or enable cgitb. Sometimes I enable
line tracing for a specific function and the functions it calls using a
tracing decorator. There are lots of things that are easier than breaking
down and learning how to use pdb. ;-)

I think the degree of familiarity you and Mike have with
Python makes using the intrinsic (for lack of a better
word) tools easier. For me, having a tool like pdb is a
big help because I am not yet familiar with the all other
options. (For example, I never heard of cgitb until just
now.) I am also pretty sure both of you can draw more
conclusions, more reliably, and from less data, then me
so one or two added print statement for you would for
me be 10 or 20.

pdb is light-weight enough that (I hope) it does not
obscure, or change what Python is doing -- something
I worry about with heavier-duty debuggers. It also
comes with Python which gives it some kind of credibilty
in my mind.

For me, it is mostly useful for understanding flow of
control and how objects change as that happens. I
find it easier than constantly modifying the source code.

 

[Scott David Daniels]

For me, it (pdb) is mostly useful for understanding flow of
control and how objects change as that happens. I
find it easier than constantly modifying the source code.

Do take a look at Komodo, in that case. Idle does a bit of a
job in this direction, and (for me) Komodo takes a great leap.
I can walk through lots of code watching the values I care about
easily in Komodo (in fact I mostly don't care for the "intelli-
sense" fillins while editing). In fact, I can even "debug" a
python app running on a remote machine and get this ability.
Pretty swift, ehhh? I have no relationship to ActiveState
except as a happy customer.

--Scott David Daniels
(e-mail address removed)

 

[Mike Meyer]

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 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.

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.

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

 

[R. Bernstein]

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.

 

[ilya]

- 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().

With python 2.4 you can do
python -m pdb.py yourscript arg1 arg2 ....

Ilya

 

[Fernando Perez]

I really like ipython. Many thanks for writing it!

Glad to hear that Version 0.7.0 coming out tomorrow...

And, as you say, it does have many many useful improvements over
python's default interpreter shell, including the ability to call the
debugger minimal fuss.

But ipython it doesn't obviate the need for a better or more complete
or more one that more closely follows conventional debugger command
syntax.

No, certainly not. I hope I didn't convey that in my message, I was just
hoping to provide a partial solution, but one which at least exists today.

I agree that the OP's suggestions would be all worthwhile improvements to pdb;
in particular, I think that following established convention on command-line
debugger interfaces is a good idea. Both lowering the mental barrier for new
users of pdb who come with a background in other tools, and easing the
integration into debugger-controller tools, are very valid points.

Cheers,

f

 

[Tino Lange]

R. Bernstein wrote:

Hi!

To summarize, I think most of us readers here like your changes or at least
didn't shout loud enough against it ;-)

As I also would like to have a more powerful and gdb-like debugging facility
in out-of-the-box python, I think it would be the best strategy to make a
consolidated patch now, send it to sf and to post a note about that on
(e-mail address removed) to get the "board's approval"

"idle" also changed dramatically during the last versions - why shouldn't
pdb also become better ... a volunteer seems to be there ;-)

Thanks for your effort and cheers,

Tino

(who is really +1 for your changes!)

 

[R. Bernstein]

R. Bernstein wrote:
To summarize, I think most of us readers here like your changes or at least
didn't shout loud enough against it ;-)

Okay. I'll gladly accept whatever positive interpretation someone
wants to offer.

As I also would like to have a more powerful and gdb-like debugging facility
in out-of-the-box python, I think it would be the best strategy to make a
consolidated patch now, send it to sf

Umm.. If you read the original post, I already *had* submitted a
patch. About two weeks ago. There is no evidence that it's been looked
at. But that's often the way things happen with large projects,
volunteers, and/or minimal resources.

My custom which I think is shared by many other programmers is to
submit a smallish patch, and see how that goes. If it is received
well, then others follow if not, then not.

In the two weeks of nonaction of that patch, I've gone much further at
least to my satisfaction, by working on my own. (Actually if you look
closely you'll see that I made 3 revisions of the patch. And there
still was a small bug that I've fixed recently in releasing the pydb
package.)

and to post a note about that on
(e-mail address removed) to get the "board's approval"

Hmmm. You seem to understand this side of things far better newbe me. Hey,
how about if you do that? Thanks!

"idle" also changed dramatically during the last versions - why shouldn't
pdb also become better ... a volunteer seems to be there ;-)

Thanks for your effort and cheers,

And thanks for your effort and cheers!

 

[Andreas Kostyrka]

Am Donnerstag, den 05.01.2006, 15:03 -0800 schrieb (e-mail address removed):

I know this sounds like brutal, but I've been developing Python code for
a decade now, and I've almost never used pdb.py. OTOH I also use gdb
only for "bt" from a core file.

Sorry to sound harsh, I do not consider manually stepping through a
program a costeffective way of debugging. Writting asserts,
instrumentisation, automatic debuggers and tracers are usually much
better spent money.

Consider how complicated it is to apply gdb or pdb say to a CGI program,
running in an embedded chroot environment?

Actually, for many things, python -i is more then enough to test and
debug code interactivly. Consider writing a settrace function, that
catches any data and control flow you might be interested.

Andreas

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDyumwHJdudm4KnO0RAmLNAJ9gI67mR0o8iTyC3Goxr3AkxT07eACglr3A
sVNmdjZ02s8EU/1qMwnqbfE=
=M9f6
-----END PGP SIGNATURE-----

 

[Andreas Kostyrka]

Am Donnerstag, den 05.01.2006, 21:34 -0800 schrieb (e-mail address removed):

I think the degree of familiarity you and Mike have with
Python makes using the intrinsic (for lack of a better
word) tools easier. For me, having a tool like pdb is a
big help because I am not yet familiar with the all other
options. (For example, I never heard of cgitb until just
now.) I am also pretty sure both of you can draw more
conclusions, more reliably, and from less data, then me
so one or two added print statement for you would for
me be 10 or 20.

pdb is light-weight enough that (I hope) it does not

Well, actually it uses the internal tracing mechanism of Python to do
the debugging so to say. As such it is nowhere even near the term
"light-weight". Actually, when it comes to execution time it's quite
heavy-weight so to say.

obscure, or change what Python is doing -- something
I worry about with heavier-duty debuggers. It also
comes with Python which gives it some kind of credibilty
in my mind.

For me, it is mostly useful for understanding flow of
control and how objects change as that happens. I
find it easier than constantly modifying the source code.

One question that is often needed is "How did we get to this place?".
The easiest solution is, putting this code in the place you are curious
about:

import traceback ; traceback.print_stack()

Andreas


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDyuyLHJdudm4KnO0RAhyDAJwMMHkviHwYXppY+8CFFcWybTp5oQCfbe7G
iYP5yEKooYUaFW4bpyXZA/E=
=naTp
-----END PGP SIGNATURE-----

 

[skip]

Andreas> Am Donnerstag, den 05.01.2006, 15:03 -0800 schrieb
Andreas> (e-mail address removed): I know this sounds like brutal, but I've been
Andreas> developing Python code for a decade now, and I've almost never
Andreas> used pdb.py. OTOH I also use gdb only for "bt" from a core
Andreas> file.

In addition, if you are running Python from gdb, when you reach the (gdb)
prompt you can source the Misc/gdbinit file that comes with the Python
distribution to get a user-defined "pystack" command that will display the
current Python stack trace. The "pystackv" command does that and displays
the values of all the local variables up the stack trace as well. The "up"
and "down" commands are overridden as well so that they display the current
Python stack frame if the current C stack frame is PyEval_EvalFrameEx (the
main interpreter loop).

I also find pdb fairly unnecessary. A combination of unittests, inserted
prints and the occasional use of cgitb is generally sufficient for my needs.

Skip