A More Focused Proposal

Wednesday October 06, 2004
As AMK has recently proposed, I think that the Python team should be focusing more on the standard library. However, I refrain from posting on python-dev to this effect any more because all I've had to contribute to the discussion is directionless whining. I consider it a given, however, that the standard library has reached a near-toxic level of bit-rot, although I rarely examine that assumption, although nits periodically come up that reinforce this impression, I hadn't ever thought of a nice "poster child", an issue with the stdlib that reflects the nature of the systematic problem.

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:
  1. occasionally blows past breakpoints due to .pyc/.py/sys.path disagreements about pathnames
  2. has no way of saving a set of breakpoints across invocations from within the debugger
  3. integration with Emacs support does not work with python packages
  4. doesn't allow you to view the stack when breaking inside a generator
  5. 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.