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 Our inclination to resolve that one was to design a new higher level traceback manipulation API, which seems relevant to this proposal as well.
I have two questions I'm hoping to get answered through this thread: - does the change in question need a PEP? Antoine seemed to think it didn't, as long as it was opt-in (via the unittest CLI etc)
I agree this isn't a PEP level change, just a normal RFE. That said, if the API design details get too confusing, a PEP may still end up being a useful way of clarifying specific details.
- 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. We made similar additions over the last couple of releases for both inspect (via inspect.Signature & inspect.Parameter) and dis (via dis.ByteCode & dis.Instruction).
I'm sure there is code out there that depends on the quadruple nature of extract_stack though, so I think we need to preserve that. Three strategies occured to me; one is to have parallel functions, one quadruple, one quintuple. A second one is to have the return value of extract_stack be a quintuple when a new keyword parameter include_locals is included. Lastly, and this is my preferred one, if we return a tuple subclass with an attribute containing a dict with the rendered data on the locals; this can be present but None, or even just absent when extract_stack was not asked to include locals.
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.
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). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia