[TIP] Annotated tracebacks

Chris Jerdonek chris.jerdonek at gmail.com
Sun Oct 19 16:10:11 PDT 2014


On Sat, Oct 18, 2014 at 2:52 AM, Robert Collins
<robertc at robertcollins.net> 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.

A lot of times, it's the value of variables in frames other than the
final frame that are needed to troubleshoot an issue.  Is the proposal
only to address variables in the final frame?  It seems like if
something will be done in the stdlib and the enhancement is limited to
the final frame, then the proposed API should be chosen so that it
wouldn't make it harder to expand the API later on to allow
information about intermediate frames.

--Chris

>
> 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.
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python



More information about the testing-in-python mailing list