[TIP] Annotated tracebacks

[Robert Collins]

On 19 Oct 2014 21:38, "holger krekel" <holger at merlinux.eu> wrote:
>
> On Sat, Oct 18, 2014 at 22:52 +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.
>
> What do you mean with "variables in parameters"


Ideally this code:

def calls():
  called(1, 2)

def called(a,b):
  a = 3
  b = 4
  1/0

would show something like:

param a=1
param b=2
local a=3
local b=4

for the frame of called.

>
> > 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.
> >
> > 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 am open to discuss what it takes to factor out or reimagine pytest's
> traceback code (tested against py26-py34,pypy) so it becomes useable from
> testtools.  You can see it in action with:

That would be great. Ideally I think this belongs in the stdlib in the
traceback module. In a pinch testtools /could/ depend on py.test and
bring it in, but I'd like to keep deps fairly shallow and focused on
things where much of the functionality is used.

If you want I can prepare a patch to traceback based on your code, or you can.

>     py.test --tb=short,long,native [--full-trace] [--showlocals] somefile.py
>
> If somefile.py contains:
>
>     def test_function():
>         i = 3
>         assert i == 4
>
> While the code for the traceback code leaves things to be desired
> (i wrote parts of it 8 years ago), it is quite battle tested because
> it overtime incorporated tests and fixes for reported bugs.
>
> Note that the assertion expression code showing (values in expressions)
> is not strictly related to traceback manipulation and can be manipulated
> separately with "--assert=rewrite|plain|reinterp"

Yeah- the assert stuff is very distinctively py.test, and its
something I'd propose we consider separately ;)

-Rob