On 1 December 2014 at 10:30, email@example.com wrote:
On Thu, Nov 27, 2014, at 19:48, Robert Collins wrote:
On 27 November 2014 at 14:12, Andrew Barnert firstname.lastname@example.org wrote:
On Nov 26, 2014, at 15:45, Robert Collins email@example.com 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.