[TIP] Annotated tracebacks
marius at gedmin.as
Sun Oct 19 23:05:29 PDT 2014
On Sat, Oct 18, 2014 at 10:52:47PM +1300, Robert Collins wrote:
> testtools just had this bug opened on it:
> Which has a few contributing issues but one in particular is that
> simple tracebacks don't give you the value of variables in parameters,
> nor of local variables in the trace.
> I'm aware of the implementation details that can make showing those
> values fraught (since __str__ and __repr__ can execute arbitrary
> code), but I thought I'd do a straw poll here and see who supports the
> idea of the traceback module itself offering to format such things
> (e.g. via a locals=False parameter to format_list and friends), which
> testtools could then backport to older pythons, and use itself to do
+1: the stdlib traceback module ought to let us provide additional
information per frame.
I'm ambivalent about outputting _all_ the locals. My brief experience
with this (in py.test) leads me to think 99% of the time all that does
is make the traceback too overwhelmingly long to read comfortably. (The
other 1% of the time the extra information is indispensable.)
In the Zope world we had a convention of showing the value of
__traceback_info__, if available in the locals of each frame. Usually
this would be a tuple with whatever locals the developer thought would
be useful to see in case of errors.
(There's also __traceback_supplement__, but it's horrible.)
I've also abused the linecache module to add extra information to
certain traceback frames: https://gist.github.com/mgedmin/4269249
> In terms of addressing the implementation details, my thoughts today
> are to render the traceback once in simple mode, and then once with
> variables, and if something throws during the variable render, just
> use the simple one.
foo = <unrepresentable>
might me more useful.
We're sysadmins. To us, data is a protocol-overhead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 173 bytes
Desc: Digital signature
More information about the testing-in-python