[Python-Dev] __trace__? (was Re: PEP 344: Explicit vs. Implicit Chaining

[Phillip J. Eby]

At 10:33 AM 5/21/2005 -0400, James Y Knight wrote:
>On May 20, 2005, at 6:37 PM, Phillip J. Eby wrote:
> > This only helps if you can get to a debugger.  What if you're
> > reading your web server's error log?
>
>Then you're in trouble anyways because you need the contents of some
>local to figure out what's going on, also.

Actually, this reminds me of something...  I've often found that tracebacks 
listing the source code are less than informative for developers using a 
library.  I've been thinking about creating a traceback formatter that 
would instead display more useful trace information, but not the 
super-verbose information dumped by cgitb, nor the cryptic and wasteful 
__traceback_info__ of Zope.

Specifically, I was thinking I would have statements like this:

     __trace__ = "Computing the value of %(attrName)s"

embedded in library code.  The traceback formatter would check each frame 
for a local named __trace__, and if present, use it as a format to display 
the frame's locals.  This information would replace only the source code 
line, so you'd still get line and file information in the traceback, but 
you'd see a summary of what that code was currently doing.  (If trying to 
format the trace information produces an error, the formatter should fall 
back to displaying the source line, and perhaps emit some information about 
the broken __trace__ -- maybe just display the original __trace__ string.)

As long as we're proposing traceback formatting enhancements, I'd like to 
suggest this one.  A sufficiently smart compiler+runtime could also 
probably optimize away __trace__ assignments, replacing them with a table 
similar to co_lnotab, but even without such a compiler, a __trace__ 
assignment is just a LOAD_CONST and STORE_FAST; not much overhead at all.

Anyway, judicious use of __trace__ in library code (including the standard 
library) would make tracebacks much more comprehensible.  You can think of 
them as docstrings for errors.  :)

Interestingly, you could perhaps implement context exceptions in terms of 
__trace__, e.g.:

     try:
         doSomething()
     except Exception, v:
         tb = v.__traceback__
         __trace__ = "Handling exception:\n%(v)s\n%(tb)s"
         # etc.

So, you'd get the formatting of the context exception embedded in the 
traceback of the error in the handler.