Comment 13 for bug 381069
Revision history for this message
| Jon Guyer (guyer) wrote Re: Cannot step debugger in IPython 0.9.1 under Python 2.6.2: Pdb instance has no attribute 'curframe' | #13 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
#8: I'm seeing a very different breakdown with my FiPy scripts on Mac OS X. Using time.time() embedded in the startup sequence for my script:
$ python r1082.py
...
startup time: 4.54922485352
----
$ python -m pdb r1082.py
(Pdb) c
...
startup time: 4.59463787079
----
$ ipython -pydb
In [1]: run -d -b 43 r1082.py
ipydb> c
...
startup time: 856.767014027
----
In contrast, using ipdb (which I didn't know about before; thank you!):
$ ipython
...
In [1]: %run r1082.py
ipdb> c
...
startup time: 4.54875421524
----
ipdb is a little clumsy to set up, but is quite usable. pydb is insane.
> As for "don't be so slow" (with apologies if this is obvious):
> * Use breakpoints (perhaps inside ad hoc "if" statements) to avoid single-stepping unproblematic parts of code.
My trouble, as above, is even getting to the code I want to single-step.
> * Use pydb.set_trace()? (Never tried that.)
Seems to work well, although if I'm going to do that, ipdb seems nicer.
> * Are you using Numpy for the computationally intensive code?
Amongst other things.
> * If you are, Cython (www.cython.org; available for Mac too) might speed up elementwise calculations.
I'm trying to *reduce* my debugging headaches! 8^)
Cython is certainly on our list of optimizations to explore, but is not the solution here. My immediate problem is not with the speed of my own code, nor with normal debugging of my code; it's this 'curframe' business and pydb that's causing me grief. Now that I know about ipdb, I can get on with things, thanks.