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.