[TIP] Annotated tracebacks

[holger krekel]

On Sun, Oct 19, 2014 at 23:50 +1300, Robert Collins wrote:
> On 19 October 2014 23:35, holger krekel <holger at merlinux.eu> wrote:
> 
> > Would be nice.  How do you propose to capture the "param" part?
> 
> NFI just yet. We could obviously start without that :).

I am asking how you could do it because i don't know :)
To capture the repr of the param, generally you'd need to
ask for the repr at function invocation time because at raising
time things might have changed.  You can achieve that with sys.settrace()
i guess.  Quite some overhead and a setting with somewhat global
effects.

> >> 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.
> 
> The code exists and is stable though - its been in py.test for a long
> time, right? So its already community adopted in a broad sense...

There is this thing that I want people to not think bad of me if they
look at my code :)

> I'd suggest the same pattern unittest2 used.
> 
> That is, publish a traceback2 module which contains the full
> implementation that would go in the stdlib and make sure that that is
> python 2.x and 3.x importable and usable, using whatever fugly hacks
> are needed. The reason I want it in the stdlib is so that I can make
> unittest in the stdlib use whatever extended API we come up with.

Quite a long term strategy.  Maybe i am just not patient enough.

Speaking about long term, what about making unittest learn about plugins?  
It's a pity Michael didn't get to finish his plugins branch yet.

> > 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 :)
> 
> Thats fantastic news and a big improvement :)

:)
holger