[TIP] Annotated tracebacks

[Marius Gedminas]

On Sat, Oct 18, 2014 at 10:52:47PM +1300, Robert Collins wrote:
> testtools just had this bug opened on it:
> 
> https://github.com/testing-cabal/testtools/issues/111
> 
> 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
> this.

+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[1] 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.)

  [1] https://github.com/zopefoundation/zope.exceptions/blob/master/src/zope/exceptions/exceptionformatter.py


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.

I think

  foo = <unrepresentable>

might me more useful.

Marius Gedminas
-- 
We're sysadmins. To us, data is a protocol-overhead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20141020/cc349969/attachment.pgp>