There are two modules that I use to debug Python code:
There are two main ways that I launch
pdb: from the command line and from a breakpoint within a script.
To launch pdb from the command line, simply run Python with the
-m pdb flag:
# py -m pdb script name
(if you're like me,
python is a bit much to type... A simple fix is to just create a link to the
python binary named
ln -s $(which python) /usr/bin/py)
The second, and much more useful, method of invoking
pdb is the
set_trace function. To break at any point in your code, simply insert the line:
import pdb; pdb.set_trace()
When the code execution gets to that point, it will stop and drop you in to a debugging shell.
Just to feel cool like the Eclipse kids, I have mapped this to F8 in Vim (
map <F8> Oimport pdb; pdb.set_trace() #BREAK<Esc>)
rpdb2 stands for Remote Python Debugger 2, and as the name suggests it allows remote debugging. This is useful if
pdb does not play well with the threading/forking in your application (it did not like web.py, for example). The other, and much greater, benefit of
rpdb2 is Winpdb. As the name suggests, Winpdb is a graphical Python debugger.
While Winpdb allows you to run your script from within the application, that is not very helpful if you are working on a beast like Drproject.
When you're working with a beastly application, it is much easier to set a
rpdb2 breakpoint and then attach Winpdb to the application. To do this, stick this line where ever you want your application to break:
import rpdb2; rpdb2.start_embedded_debugger("asdf")
When your application gets to that line, it will "hang" as the debugger runs. Now it's time to fire up Winpdb and attach (File --> Attach) to the process. The password is "asdf". After it loads, you will be able to do debug the application like normal.
One final note about using
rpdb2: to run a Python command (for instance, in the bottom right window of Winpdb), you have to prefix it with
exec (for instance,
exec print foo).