That's an interesting idea but the objective is not to only produce a backwards compatible version but also a maintainable solution that also doesn't have weird side effects or strange behaviour. I find things that behaves like that a bit surprising. But this is something we could certainly do.
On Sun, 17 Apr 2022, 20:40 MRAB, <pyt...@mrabarnett.plus.com> wrote: > On 2022-04-17 18:20, Pablo Galindo Salgado wrote: > > Hi, > > > > We are currently debating in gh-88116 > > (https://github.com/python/cpython/issues/88116 > > <https://github.com/python/cpython/issues/88116>) > > what's the best way forward to update the APIs in the inspect module to > > include the new position information. > > > > These APIs are inspect.getframeinfo, inspect.getouterframes, > > inspect.getinnerframes, inspect.stack and inspect.trace. > > > > The problem is that these APIs return a named tuple that now needs to > > include several new attributes (or one 4 tuple for > > the positions). Being named tuples, if we add a new attribute, existing > > unpackings of the tuple will now fail because there > > are more elements or the elements are in different positions. Also, it > > will be quite weird to add the new attributes at the > > end but leave the line number at the beginning. > > > > 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). I personally > > find this quite confusing but it certainly works. There may be other > > options. > > > > What do you think? > > > Why not allow indexed access to the extra attributes? > > You could return only the current attributes by default, but the extra > attributes on demand. (Slightly strange, but backwards-compatible.) > Slicing could also return what was requested, e.g. t[ : 4] would return > the first 4, t[ : 5] the first 5, t[ : ] all of them, etc. (Again, > strange, but backwards-compatible.) > _______________________________________________ > 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/I7EX35AYMMXGH3N3KOCCPLAUYCHGISJP/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/IT6KQT6IWVFECHY3LKKAN6UCZIHFJWMJ/ Code of Conduct: http://python.org/psf/codeofconduct/
