Home Original page

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

Robert Collins robertc at robertcollins.net
Mon Jan 19 00:41:25 CET 2015 
On 1 December 2014 at 10:30,  <random832 at fastmail.us> wrote:
>
>
> On Thu, Nov 27, 2014, at 19:48, Robert Collins wrote:
>> On 27 November 2014 at 14:12, Andrew Barnert <abarnert at yahoo.com> wrote:
>> > On Nov 26, 2014, at 15:45, Robert Collins <robertc at robertcollins.net> wrote:
>>
>> >> 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.
>> >
>> > There are lots of other cases in the stdlib where something is usable as a tuple of n fields or as a structseq/namedtuple of >n fields: stat results, struct_tm, etc. So, why not do the same thing here?
>>
>> Because backwards compatibility. Moving to a namedtuple is fine -
>> changing the length of the tuple is a problem.
>
> Er, but what is being suggested is to do the same backwards-compatible
> thing: move to a namedtuple-like object with extra non-tuple fields,
> just like those others. I'm confused as to what is the conflict here.

The thing I was missing is that Andrew was referring to a C only API -
AFAICT there is no Python equivalent to PyStructSequence (other than
implementing __len__ etc oneself - which is fine, but its not
structseq then, AIUI. NamedTuple would imply changing the length - and
there's no reason to reimplement traceback as C, so I'd rather not do
that.

Anyhow, looks like there is a strong desire for a fresh API anyway in
17911, so I'm just going to do that.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
More information about the Python-ideas mailing list