[Python-ideas] Extending traceback to (optionally) format and show locals.

[Robert Collins]

On 27 November 2014 at 16:08, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 27 November 2014 at 09:45, Robert Collins <robertc at robertcollins.net> wrote:
>> For context please see http://bugs.python.org/issue22937 and
>> http://bugs.python.org/issue22936.
>
> Another useful bit of context is the current RFE to have a way to
> extract and save a traceback *summary* that omits the local variable
> details: http://bugs.python.org/issue17911

AIUI the specific desire is to allow a minimal cost capture of
tracebacks without frames (so as to allow gc), with enough data to
render  a traceback later should the thing turn out to escape the
system. So largely skipping linecache lookup etc.

I think thats a good thing to do :).

> Our inclination to resolve that one was to design a new higher level
> traceback manipulation API, which seems relevant to this proposal as
> well.
....
>>  - Is my implementation approach sound (for traceback, unittest I
>> think I have covered :))?
>>
>> Implementation wise, I think its useful to work in the current
>> traceback module layout - that is to alter extract_stack to
>> (optionally) include rendered data about locals and then look for that
>> and format it in format_list.
>
> For 17911, we're not so sure about that - there's a strong case to be
> made for exposing a new object-oriented API, rather than continuing
> with the C-style "records + functions that work on them" model that
> the traceback module currently uses.

There's a nice functional feel there more than a C thing, IMO - in
that there is no hidden state, and everything is laid out for direct
view.

OTOH I've no objection to a more objects-and-methods feel, though
we'll want a thunk through to the new code which will essentially just
be constructing objects just-in-time. Seems straight forward enough to
write though.

> Fourth, expand the new ExceptionSummary API proposed in 17911 to also
> include the ability to *optionally* preserve the local variable data
> from the stack frame, rather than always discarding it.

A couple of other related things I should be clear about: I want
something I can backport successfully via traceback2, for use in
unittest2. I don't see any issue with the proposal so far, other than
the linecache API change needed to support __loader__, which implies a
linecache2 backport as well.

>> The last option is my preferred one because the other two both imply
>> having a data structure which is likely to break existing code - and
>> while you'd have to opt into having them it seems likely to require a
>> systematic set of upgrades vs having an optional attribute that can be
>> looked up.
>>
>> So - thoughts?
>
> I don't see a lot of value in adhering too strictly to the current API
> design model - I think it would make more sense to design a new higher
> level API, and then look at including some elements to make it easy to
> adopt the new tools in existing code without having to rewrite the
> world (e.g. the inspect module work in Python 3.4 that switched the
> legacy APIs to actually call the new inspect.signature API internally,
> greatly expanding the scope of the types they could handle).

Sure. AIUI noone is actively pushing on the new thing, so I'll put my
hand up for it now and we'll see where I get to in my available
cycles.

-Rob

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