-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Py_GenericAlias is not documented #88558
Comments
Py_GenericAlias seems to be a public API given its name and is mention in the stable ABI list for 3.10 (https://docs.python.org/3.10/c-api/stable.html?highlight=py_genericalias), but the API is not documented. Likewise for Py_GenericAliasType. |
Ronald, may I take this please? Or are you working on something already? |
I'm not working on this. Feel free to work on a PR. |
Hm, maybe it was a mistake to expose this? Remind me what use is made of this from C code? Can we remove this from the stable API during beta? It was never exposed before. |
It could be useful for C extensions that want to support PEP-585 for their types, such as numpy's array type. |
Hm, but is that what they are doing? I assume that they use stub files, since static type checkers don’t introspect the runtime API. |
They'd still need runtime support from GenericAlias to allow users to write |
I was wondering if this was accidentally added at the time too.
It's required for a C extension type to implement the class_getitem method properly. Eg.
Unfortunately, it seems like it has been (accidentally?) exposed since 3.9 :(. I see some 3rd party projects using it already, so I don't know if we can get rid of it so easily: CC-ing Petr, seeking advice on the C stable ABI for this please. |
Maybe the docs then should contain a more-or-less complete example showing how a 3rd party type should use this? |
(Copied over from the PR) BTW, I also noticed the stable ABI manifest exposes the wrong return type for Py_GenericAliasType. It exposes it as a function when it's a var/type/struct. So I fixed that in the PR too otherwise the docs weren't compiling (I can split that into a separate PR if needed). But that means the exported symbol for Windows is also modified. |
It was added (to PC/python3.def) in 3.9, so removing in 3.10 beta wouldn't be good. |
Why should this be deprecated at all? The API is a convenient way to add I noticed the lack of documentation when I worked on implementing this for PyObjC (an easy first step towards adding type stubs to that project). For me the alternative to using Py_GenericAlias would be a dummy implementation of |
Does it need a backport to 3.9 too, since GenericAlias was introduced there? |
I'm closing this issue as all the relevant PRs have landed. Thanks everyone!
I can't speak for others, but personally I think it's here to stay (for the many reasons raised in the previous messages). Thanks for catching and reporting this. Improving docs is always fun :). |
Py_GenericAliasType
in stable ABI #26739Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: