My .pdbrc

Sunday 8 April 2007This is close to 18 years old. Be careful.

When I need a Python debugger, I use the standard pdb debugger. I’m very low-tech about it: I set breakpoints by adding this line to my source:

import pdb; pdb.set_trace()

It’s the only time I use the Python semicolon, and I always use it for this line.

This breaks me into the debugger when the line is executed, and I can step, examine, and so on, from there. The one aid I have is a small .pdbrc file to define a few handy shortcuts for me:

# Ned's .pdbrc

# Print a dictionary, sorted. %1 is the dict, %2 is the prefix for the names.
alias p_ for k in sorted(%1.keys()): print "%s%-15s= %-80.80s" % ("%2",k,repr(%1[k]))

# Print the member variables of a thing.
alias pi p_ %1.__dict__ %1.

# Print the member variables of self.
alias ps pi self

# Print the locals.
alias pl p_ locals() local:

# Next and list, and step and list.
alias nl n;;l
alias sl s;;l

This defines useful commands for printing members of expressions, members of self, and locals. Not a huge step forward, but helpful nonetheless.

There are other Python debuggers, but whenever I try them, I get tangled up in configurations and connections and IDEs. PDB just works, even though it is very basic. Someday I’ll find a better one, but for now it serves my needs.

Update: from the comments, a link to a cool way to get more interesting helper functions into the .pdbrc file: have it read an external Python file.

Comments

[gravatar]
I have found winpdb to be easy to set up and use.
[gravatar]
Pdb is my favourite too! You're the second person I know in the world who uses pdb.
[gravatar]
You should try epdb--it's an enhanced version of pdb with a lot of very nice features:

l and l- for moving backwards and forwards in source, and you can do: func? to get the signature of the object or func?? to get the docstring. It also has tab competion, conditional breakspoints, "until " to continue code execution until a certain point, etc.
[gravatar]
@Tim: It might be nice, but it doesn't work on Win32 (and is very hard to find - ftp://download.rpath.com/epdb/ if you're interested)
[gravatar]
If you use pdb with emacs, it tracks the location in the source for you, most of the time, so you don't need the step-and-list aliases.
[gravatar]
I agree about the set_trace, but I also can't live withtout this tip for code completion:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498182
[gravatar]
I've always felt shamefully simple by inserting "import pdb; pdb.set_trace()" into code I need to debug. Visions of sophisticated breakpoint management, Java IDE users smirking and shaking their heads, teasing whispers that there must be a *better* way of debugging python flash and fade. I won't feel that way tomorrow, though. Simple isn't only better, it's ok, too. Thanks, Ned!
[gravatar]
>I agree about the set_trace, but I also can't live withtout this tip for code completion:
>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498182

Thanks Paulo.

For those that want to take this trick a step further, I've submitted a patch to make this behaviour default in pdb. You can find the patch here: http://sourceforge.net/tracker/index.php?func=detail&aid=1641544&group_id=5470&atid=305470
[gravatar]
- for k in sorted(%1.keys())
+ for k in sorted(%1)

sorted will call iter for you, and iter(dict) is approximately the same as dict.iterkeys().
[gravatar]
Quitting pdb is not graceful as it vomits a scary pile of errors. I found a way to gracefully exit by editing a module imported by pdb called "bdb".

# acknowledgement: stackoverflow.com/questions/173278/
# docs.python.org/3/library/os.html#os._exit

look for "def dispatch_line"
comment out line 69: if self.quitting: raise BdbQuit
add new if clause: if self.quitting: os._exit(1)

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.