Re: pdb.py - why is this debugger different from all other debuggers?
Andreas> Am Donnerstag, den 05.01.2006, 15:03 -0800 schrieb Andreas> [EMAIL PROTECTED]: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
Am Donnerstag, den 05.01.2006, 21:34 -0800 schrieb [EMAIL PROTECTED]: > [EMAIL PROTECTED] wrote: > > 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 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 > signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
Am Donnerstag, den 05.01.2006, 15:03 -0800 schrieb [EMAIL PROTECTED]: 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. > signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
Tino Lange <[EMAIL PROTECTED]> writes: > 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 > python-dev@python.org 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! -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
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 python-dev@python.org 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!) -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
R. Bernstein wrote: > Fernando Perez <[EMAIL PROTECTED]> suggests: >> 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! 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
> - 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
Mike Meyer <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
[EMAIL PROTECTED] (R. Bernstein) writes: > Mike Meyer <[EMAIL PROTECTED]> 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. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
[EMAIL PROTECTED] wrote: > 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 [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
[EMAIL PROTECTED] wrote: > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
Mike Meyer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] 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! -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
[EMAIL PROTECTED] writes: > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
Fernando Perez <[EMAIL PROTECTED]> suggests: > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
[EMAIL PROTECTED] writes: > "R. Bernstein" <[EMAIL PROTECTED]> wrote: >> 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. 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. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
[EMAIL PROTECTED] wrote: > 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pdb.py - why is this debugger different from all other debuggers?
"R. Bernstein" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
pdb.py - why is this debugger different from all other debuggers?
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 call