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

[random832 at fastmail.us]

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.