A good list of libraries, but please, don't use this in the middle of your code to set a break point: import pdb; pdb.set_trace(); There's a chance you forget this, check-in, and it ends in production. Use pdb facilities instead: $ python -m pdb Then set a breakpoint and continue: (Pdb) break : (Pdb) c This is trivial to automate from any editor or command line, so you don't even have to guess the path to the file. E…
Since I claimed it was trivial to automate that from an editor, here's a plugin for setting up breakpoints on ST2:
One thing I love about much-maligned Tcl is its ability to connect a repl to a running program. Not just remote debugging of a halted program - you can actually inspect and alter variables and issue commands into the executing code. Is there a way to do that in, say, Python?
All Python debuggers allow you to execute statements, on top of navigating the stack.
The most frustrating thing (experienced in both Javascript and Python) is the "oh uncaught exception? let me just quit everything" model. Most of the time, if I were just given an interactive prompt right then, I could spend 1 minute looking at local variables, maybe get a special stack trace variable to look at that, then be over with it. Instead I have to stick in some print statements and start everything over aga…
And what if your bug is after the nth iteration of the loop, where the exact value of n is unknown (it's a bug, after all)? How many times are you going to set the variable and run the loop n times? Whereas with print-debugging and a grep you can filter for only unexpected/unusual output, and so narrow down to the likely cause, faster. Generalizing, of course. There are definitely cases where a debugger can be more e…
I'd set a conditional breakpoint: (gdb)> break Breakpoint 1 at .... (gdb)> cond 1 x cont And now, it will execute until 'x 42', then it triggers. Although, to be honest, I mostly use a debugger as an exploratory printf these days: (gdb)> call pretty_print(my_data) I do mainly use printf as the front line of debugging, though, with several debug switches on the command line. I follow up by jumping to a debugger once I…
Yes, conditional breakpoints can be helpful - good point. You missed the case of x == 42, in a hurry, I guess. cond should be x <= 42.
The most frustrating thing (experienced in both Javascript and Python) is the "oh uncaught exception? let me just quit everything" model. Most of the time, if I were just given an interactive prompt right then, I could spend 1 minute looking at local variables, maybe get a special stack trace variable to look at that, then be over with it. Instead I have to stick in some print statements and start everything over aga…
There's a nice trick to enable this behavior for standard Python code run at the command line. Write the body of your code inside a main() function, then call it using the following toplevel block: if __name__ == "__main__": try: main() except KeyboardInterrupt: # allow ctrl-C raise except Exception as e: import sys, traceback, pdb print e type, value, tb = sys.exc_info() traceback.print_exc() pdb.post_mortem(tb) Thi…
You don't need this trickery.
$ python -m pdb yourscript.py
(Pdb) c
Will let you inspect the local scope after an uncaught exception.
And what if your bug is after the nth iteration of the loop, where the exact value of n is unknown (it's a bug, after all)? How many times are you going to set the variable and run the loop n times? Whereas with print-debugging and a grep you can filter for only unexpected/unusual output, and so narrow down to the likely cause, faster. Generalizing, of course. There are definitely cases where a debugger can be more e…
I'd set a conditional breakpoint: (gdb)> break Breakpoint 1 at .... (gdb)> cond 1 x cont And now, it will execute until 'x 42', then it triggers. Although, to be honest, I mostly use a debugger as an exploratory printf these days: (gdb)> call pretty_print(my_data) I do mainly use printf as the front line of debugging, though, with several debug switches on the command line. I follow up by jumping to a debugger once I…
Backward stepping is cool. When I was checking out various Lisps some time ago, I saw in (IIRC) Franz Lisp that they had something like Visual Studio's Edit and Continue (maybe before VS did). Not a Lisper myself, though I've dabbled in it now and then and like it, so maybe that has been a feature of Lisps from much before - don't know.
One thing I love about much-maligned Tcl is its ability to connect a repl to a running program. Not just remote debugging of a halted program - you can actually inspect and alter variables and issue commands into the executing code. Is there a way to do that in, say, Python?
All Python debuggers allow you to execute statements, on top of navigating the stack.
Python debuggers, as far as I know, require the program to be in a halted state - i.e., you're stepping through it.
In Tcl, the program can be running its event loop at normal speed, and you can inject commands into that event loop while it runs.
I'd set a conditional breakpoint: (gdb)> break Breakpoint 1 at .... (gdb)> cond 1 x cont And now, it will execute until 'x 42', then it triggers. Although, to be honest, I mostly use a debugger as an exploratory printf these days: (gdb)> call pretty_print(my_data) I do mainly use printf as the front line of debugging, though, with several debug switches on the command line. I follow up by jumping to a debugger once I…
Backward stepping is cool. When I was checking out various Lisps some time ago, I saw in (IIRC) Franz Lisp that they had something like Visual Studio's Edit and Continue (maybe before VS did). Not a Lisper myself, though I've dabbled in it now and then and like it, so maybe that has been a feature of Lisps from much before - don't know.
There's a nice trick to enable this behavior for standard Python code run at the command line. Write the body of your code inside a main() function, then call it using the following toplevel block: if __name__ == "__main__": try: main() except KeyboardInterrupt: # allow ctrl-C raise except Exception as e: import sys, traceback, pdb print e type, value, tb = sys.exc_info() traceback.print_exc() pdb.post_mortem(tb) Thi…
You don't need this trickery. $ python -m pdb yourscript.py (Pdb) c Will let you inspect the local scope after an uncaught exception.
Yeah, that's probably a better general solution. That said, there are some contexts, e.g. working on academic research code which is always buggy, where you really do want debugger-on-exception to be the default behavior, so that you don't have to remember to type -m pdb every single time you run your code. I guess you could alias python to "python -m pdb", but that's opening a whole new can of worms. :-)