[Python-Dev] Re: Updating inspect APIs

[Antoine Pitrou]

On Sun, 17 Apr 2022 19:00:45 -0700
Guido van Rossum  wrote:
> Is it not acceptable to create new functions that return non-named-tuple
> objects (e.g. dataclasses with slots)?

I'd advocate creating a single new function that provides more
structured access to that various information, like we did with
`inspect.signature()`.

We also don't have to formally deprecate the older APIs, just recommend
the new one in the docs.

Regards

Antoine.



> Otherwise the way the stats result
> tuple works is a reasonable approach (and possibly deprecate indexed
> access?)
> 
> On Sun, Apr 17, 2022 at 10:23 AM Pablo Galindo Salgado 
> wrote:
> 
> > Hi,
> >
> > We are currently debating in gh-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?
> >
> > Cheers from sunny London,
> > Pablo Galindo Salgado
> > ___
> > 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/RTGG637WWPOWUHUF6TRJYUSBYYSVUPRA/
> > 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/FNEUYHG6O7XM6N5NQMNXG7IL2PCEYIEI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[Petr Viktorin]

On 17. 04. 22 19:20, Pablo Galindo Salgado wrote:

Hi,

We are currently debating in gh-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.


IMO, that is the way to do it -- PyStructSequence.


I'd then discourage indexed access. It is indeed confusing, but that's 
OK for something that's only there for backwards compatibility:

- users who are confused should read the docs and update their code.
- core devs can hopefully read a comment nearby and not be confused.

(And I don't think it's worth deprecating and removing indexed access -- 
there's no reason to break code that works just because there's now a 
better API.)

___
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/YX2F3U5ALP6XBPZOTNITCLBGFFWTIWKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[Guido van Rossum]

Is it not acceptable to create new functions that return non-named-tuple
objects (e.g. dataclasses with slots)? Otherwise the way the stats result
tuple works is a reasonable approach (and possibly deprecate indexed
access?)

On Sun, Apr 17, 2022 at 10:23 AM Pablo Galindo Salgado 
wrote:

> Hi,
>
> We are currently debating in gh-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?
>
> Cheers from sunny London,
> Pablo Galindo Salgado
> ___
> 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/RTGG637WWPOWUHUF6TRJYUSBYYSVUPRA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/2YDFNBBGAW2QHVGPVQZBR2DINATSHM45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[MRAB]

On 2022-04-18 01:23, Steven D'Aprano wrote:

On Sun, Apr 17, 2022 at 08:35:06PM +0100, MRAB wrote:

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.)


Having len(a) and len(a[:]) be different would not be "slightly
strange", it would go against 30+ years of the expectation that the
empty slice makes a shallow copy of tuples and other sequences.


But apart from that? :-)
___
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/7U7E7E5QOBOUVOC4HUQ525FWA4X3WFKM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[Steven D'Aprano]

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/

[Python-Dev] Re: Updating inspect APIs

[Steven D'Aprano]

On Sun, Apr 17, 2022 at 08:35:06PM +0100, MRAB wrote:

> 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.)

Having len(a) and len(a[:]) be different would not be "slightly 
strange", it would go against 30+ years of the expectation that the 
empty slice makes a shallow copy of tuples and other sequences.


-- 
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/2GFHPI3ZDEIVG72GEDN53F3WMLS3JECC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[Eric V. Smith]

Things like os.stat_result use PyStructSequence_NewType, which is the C 
equivalent of a namedtuple. But a Struct Sequence has the extension of 
being able to have more named fields than the tuple length. It was 
designed, so I understand, just for cases like this. I don't know if it 
would be possible for you to use it from pure Python code, or maybe 
you'd need a C module to expose it.


There was idle talk many years ago of either extending namedtuple or 
creating some new type factory that could do the same from pure Python 
code, but no one ever got serious about it. I'm not sure it would be 
accepted in any event. Buy maybe if you have a concrete use case 
something like that could be done.


Eric

On 4/17/2022 1:20 PM, Pablo Galindo Salgado wrote:

Hi,

We are currently debating in gh-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?

Cheers from sunny London,
Pablo Galindo Salgado

___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/RTGG637WWPOWUHUF6TRJYUSBYYSVUPRA/
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/JRVT7YZGXTWPJACWAOKR4EUPO6IZIBJQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[Pablo Galindo Salgado]

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,  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
> > )
> > 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/

[Python-Dev] Re: Updating inspect APIs

[MRAB]

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 
)
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/