[Python-Dev] __trace__? (was Re: PEP 344: Explicit vs. Implicit Chaining
Phillip J. Eby
pje at telecommunity.com
Mon May 23 15:06:17 CEST 2005
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.
More information about the Python-Dev
mailing list