On Thu, Nov 27, 2014, at 19:48, Robert Collins wrote:
On 27 November 2014 at 14:12, Andrew Barnert <abarnert@yahoo.com> wrote:
On Nov 26, 2014, at 15:45, Robert Collins <robertc@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.