On 1/5/07, belinda thom <bthom at cs.hmc.edu> wrote:
> What I am currently not thrilled about w/the way I develop code in
> ipython is that I find I often have to modify the code itself to
> debug in a location I'm interested in.
>> Suppose I had a module foo.py:
>>> class blah:
>> <some class def'n stuff, including a method called bar>
>> <perhaps some other classes or functions...>
>> <the if __name__ == "__main__" check>:
>> b = blah(...)
> b.foo(...)
>>> When I wish to debug foo, this works fine, but then I want to debug
> other things, so I have to keep adding code I'd like to execute to
> the bottom of a file. What I'd much rather prefer is to be able to
> execute commands at the ipython command-line and have them just stop
> in the debugger at a particular line-number that I specify. Ideally,
> this would be "mouse-clickable" but I think the emacs/ipython code is
> not currently being actively developed (perhaps I'll get around to an
> extension like this someday; I dunno; I'm a big fan of emacs and use
> it for just about everything). But short of mouse-clickable, I'd like
> to be able to set a breakpoint in foo.py w/o having to add code at
> the bottom of the file to get it to break where I am asking it to
> when I use run.
>> Am I missing something really basic? Or does this type of debugging
> scheme (which I used heavily in Matlab) not make sense when
> developing Python code (and if so, why?)?
I'm not sure if the python debugger facilities allow for that kind of
fine-grained control that you describe, and which is typical of good
IDEs. I personally seem to get by with plain old print statements and
the occasional brute-force insertion of
1/0
where I want to see something; I just activate %debug after the crash
and go looking for debris.
But it is possible to have a minimally intrusive activation of a local
debugger in Python, the pdb.set_trace() function is meant for that.
Since I couldn't seem to take a taunt about matlab, against my better
judgement I decided to spend the canonical '10 minutes' adding this
support to IPython (so that you can use set_trace but get the nicer
IPython debugger).
http://projects.scipy.org/ipython/ipython/changeset/2014
has the results, which proved to be a bit more complicated than I
expected but work correctly both inside and outside of IPython, and
have more graceful behavior at exit than set_trace.
If you can update SVN and give us some feedback, that would be good
(it better work, Brian is going to kill me for not working on the
other branch :).
The constructor for Tracer:
http://projects.scipy.org/ipython/ipython/changeset/2014#file0
has a usage example (line 101), reproduced here:
Usage example:
from IPython.Debugger import Tracer; debug_here = Tracer()
... later in your code
debug_here() # -> will open up the debugger at that point.
Once the debugger activates, you can use all of its regular commands to
step through code, set breakpoints, etc. See the pdb documentation
from the Python standard library for usage details.
This does /not/ satisfy your constraint of not having to modify your
code, but hopefully the modification is minimal: one line at the top
of your module and a single call where you want to open the debugger.
> Again, thanks for your thoughtful and well-considered answers. One
> great thing about python-related lists is that so many people are
> excited about it that it is easy to jumpstart learning online.
I will unfortunately delay a bit my reply to your other question, as
I'm really swamped. Perhaps others can offer insight.
Best,
f