On 27 November 2014 at 16:08, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 27 November 2014 at 09:45, Robert Collins <robertc@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@hp.com> Distinguished Technologist HP Converged Cloud