At 02:33 PM 1/28/2010 +0100, Benjamin Schweizer wrote:
Hello,
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
http://benjamin-schweizer.de/improved-python-traceback-module.html
May I suggest a possible improvement to fix the "sensitive
information" question you raised, as well as offering an improvement
in compactness/readability?
If you look for a local variable in each frame containing a format
string, let's say __trace__, you could apply that format string to a
locals+globals dictionary for the frame, in place of dumping all the
locals by default. This would allow one to customize the tracing
information along the lines of:
__trace__ = "Discombobulating %(thing)s"
for thing in other_thing:
discombobulate(thing)
And you would then get a very nice, nearly user-readable traceback
showing the context of what's going on. (It should probably use
new-style string formatting instead of old-style, of course, but you
get the idea.)
This is an idea that's been on my back-burner for ages, as some of my
libraries and frameworks make calls into user code in such a way that
the context of what's happening is not so obvious. A traceback that
can state the *intention* of what's going on in a given stack frame
could add a lot of valuable context for interpreting what's going on
-- especially if this became a standard available feature in the language.
(In principle, a Python VM could later omit assignments to __trace__
when -O or -OO is used, or even optimize away constant __trace__
assignments altogether, by saving them with associated line ranges,
similar to how co_lnotab allowed optimizing away the SET_LINENO opcode.)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
