The other day, when trying to hunt down a bug in my own code, I found a perfect example of this, though, and I think it should be a point of reflection for the Python team. Let me dress up this next point a bit, for emphasis:
The standard library does not provide a functioning debugger.
But what about
pdb.py, you might ask? Well, pdb:- occasionally blows past breakpoints due to .pyc/.py/sys.path disagreements about pathnames
- has no way of saving a set of breakpoints across invocations from within the debugger
- integration with Emacs support does not work with python packages
- doesn't allow you to view the stack when breaking inside a generator
- provides no support for remote debugging or IDEs
There are probably even more issues than this, but I generally use a set of hacks included with Twisted and Twisted's Emacs support to work around these deficiencies.
These are also problems with basic functionality. There are other things I think a Python debugger should be able to do, for example, "fix and continue", which even environments working with a far less flexible language (for example, Microsoft Visual C++) manage to do.
So, I will focus on this point, for future discussion of Python development, to avoid unproductive discussion of differences of style and taste. I think we should all be able to agree that the Python debugger should not be broken in basic ways, such as missing breakpoints, and should work with all aspects of the language, including generators and list comprehensions.
Posts
6 comments:
Here's a link to that "set of hacks" glyph mentions.
(Hmm, I haven't checked out that file lately.)
You do realize that "fix and continue", at the least, would require major hacking of the Python interpreter? I thought we weren't supposed to be doing that any more.
To quote amk's proposal directly:
"We should deflect effort away from language changes and redirect them toward the standard library."
This is really what I'm interested in, not so much movement towards or away from the interpreter.
Actually, I think "fix and continue" is easier than you make it out to be: the existence of the "jump" command in pdb implies that at least some of the groundwork is already there, somewhere. But it's still too hard for me, so I'll reserve judgement.
Yeah, I guess I wasn't so much bitching at you or amk, more at some of the 'me toos' that I've seen...
Uh, I reviewed and checked in the patch implementing the jump command in pdb :) I hope I know what I'm talking about in this area...
Great to see you take this initiative! I've been working on pdb a bit myself. Be sure to search through the patches before you start any work though. For example, there's already a patch open about remote debugging. It would be great if you could see whether it's satisfactory.
Also, does the version in CVS still miss a lot of breakpoints? I checked in a patch fixing some of the logic about a month ago.
> Excellent! What do you think of this idea, then:
It's interesting! I think it might be very hard to make reliable (in particular, pdb's "jump" command has limitations that might be really frustrating in practice).
What I really would like is resumable exceptions and CL-style tricks of being able to fix the code and pretend the exception never happened, except that's really impossible to implement unless you have something like stackless, and even then ... etc ... this is one of the reasons I work on PyPy :-)
Post a Comment