[TIP] Annotated tracebacks

[holger krekel]

On Sun, Oct 19, 2014 at 23:07 +1300, Robert Collins wrote:
> 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.

Would be nice.  How do you propose to capture the "param" part?

> > > 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.

I am not keen on including in stdlib first.  The place for things to be
adopted by the community is PyPI these days.  Which also helps to heal the
py2/py3 chasm.  It it's stable and used a lot it could go to stdlib later.
Anyway, let's first get the design/requirements right (see also question
above).  After that i can look at the code and suggest something.  
IIRC it has one abstraction layer more than is strictly needed
which originated from PyPy needs which i am not sure are still actual.

> >     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 ;)

Sure.  I'd just like to make sure you know that pytest is since years
not using "re-interpretation" but AST-rewriting such that expressions
are not evaluated twice :)

best,
holger