On Nov 27, 2014, at 16:48, Robert Collins <robertc@robertcollins.net> 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.
That's the whole point: you're _not_ changing the length. Again, look at the examples that are already in the stdlib: they have a fixed length as a tuple, with extra fields accessible by name only. And it's dead easy to do with structseq.