[TIP] Annotated tracebacks

[Robert Collins]

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


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

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.


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

-Rob

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