[TIP] Annotated tracebacks

[holger krekel]

On Mon, Oct 20, 2014 at 08:40 +1300, Robert Collins wrote:
> On 20 October 2014 00:24, holger krekel <holger at merlinux.eu> wrote:
> > 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.
> 
> I need to look at the frame representation in a few python VM
> implementations I guess - whether its copied into locals as part of
> call setup, or whether there is a transient binding we can grab from
> the caller. Lets put that on the back burner for now; getting locals
> annotated would be a major win for many environments.
> 
> > There is this thing that I want people to not think bad of me if they
> > look at my code :)
> 
> Ok, so you'll make the module then? <grin>.

TBH, I'll not get to this soon as it's not a pressing issue for me.
If you feel like looking, check out https://bitbucket.org/hpk42/py
and py/_code/code.py and "py.test testing/code/" to run its tests.
The basic API is "excinfo = py.code.ExceptionInfo(...)" and 
"r = excinfo.getrepr(...)" and then "str(r)".  You can pass in
some options to getrepr().

> >> 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.
> 
> Getting it into the stdlib might be just a couple months. Waiting for
> 2.7 to die is many years, so we need some strategy ;)
>
> > 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.
> 
> It has indeed stalled, but he says Nose2 is basically it. I haven't
> had a chance to review and reflect on it yet. I've some fairly deep
> refactorings I want to do to the reporting and execution path in
> unittest (that we've prototyped in testtools) and I don't want to
> propose a plugin to core that would conflict with that... OTOH I don't
> want to re-do his work.

FYI I am working with some people on pulling out the plugin manager part
of pytest because others and myself want to use it in other projects.
No promises when but it's so far away i think because i need it myself :)
The mechanisms have been quite successful, i'd say, because very few of
the roughly 100 plugins ever break despite several internal
refactorings in the last couple of years.

cheers,
holger