On Sun, Apr 17, 2022 at 06:20:53PM +0100, Pablo Galindo Salgado wrote:
> These APIs are inspect.getframeinfo, inspect.getouterframes,
> inspect.getinnerframes, inspect.stack and inspect.trace.
Are you referring to the FrameInfo namedtuple rather than the functions
themselves?
inspect.stack() and .trace() return lists, that part is not changing?
> What's the best way to proceed here? The suggested way is to create a
> namedtuple subclass that adds the extra attributes but doesn't allow
> indexed access to it (there is a precedent to this in how we handled
> updating os.stat_result).
That seems fine to me. It's simple, it works, its extensible, we have
precedent, it doesn't break backwards compatibility.
+1
Alternative: depreciate the current APIs and introduce new ones. But
that's going to be disruptive and difficult and hard to use, and not
extensible in the future if there's another change to the API.
Even though I just suggested it I actually dislike it :-)
-1
If you really like indexed access, you could give FrameInfo tuples a
method that returns all the field values as a tuple (or list?):
fi = inspect.stack()[0]
fi.fields() # returns a sequence of indefinite length
with no future guarantees as to the length of that sequence, only that
future fields will be added to the end, and the existing order will be
preserved.
Honestly I feel that this is overkill, but for those who really like the
tuple interface that might be a way forward.
--
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/HHFJNCJFN6UQSNE3FDICOV527NMFTADH/
Code of Conduct: http://python.org/psf/codeofconduct/
