[TIP] Annotated tracebacks

Robert Collins robertc at robertcollins.net
Sun Oct 19 12:40:41 PDT 2014


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

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

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the testing-in-python mailing list