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

[Andrew Barnert]

On Nov 26, 2014, at 15:45, Robert Collins <robertc at robertcollins.net> wrote:

> For context please see http://bugs.python.org/issue22937 and
> http://bugs.python.org/issue22936.
> 
> 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)
> - 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.
> 
> 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?

> 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?
> 
> -Rob
> 
> 
> -- 
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/