-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
MNT: Adopt pythoncapi-compat? #26158
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
Comments
This proposal seems like the right way to go to me. We now have other git submodules, and these compat functions are probably going to be updated semi-regularly during the 3.13/3.14 release cycles. An extra git submodule is preferable over copy-pasting (LoC count difference as discussed in gh-18713 isn't too relevant here). |
You might also look at my experimental https://github.com/vstinner/deadparrot/ project which is similar to pythoncapi-compat, but it's implemented as a shared library, rather than a header file. It might be harder to integrate in numpy. |
It's possible to integrate a shared library, but we don't have any yet. It'd be slightly annoying because we'd have to deal with settings RPATHs and things like Is there an advantage to using |
My plan for the future is to backport/forward port way more complicated functions which don't fit into pythoncapi-compat.h. But numpy should not really need them, so pythoncapi-compat.h should be better fit for your practical constraints. |
We added the submodule in #26189 |
As noted in PEP 703, C API functions returning borrowed references are problematic in the nogil build of Python, and new functions are available in Python 3.13 that return new references.
Three years ago @vstinner proposed vendoring
pythoncapi-compat
to replacenpy3k_compat.h
in #18713 and that was rejected.Unlike that proposal, I don't want to expose
pythoncapi-compat.h
in the public numpy C API, instead I'd only like to use it internally, replacing the internalnpy_pycompat.h
header. That means concerns raised in that PR about requiring C99 or adding potentially problematic constructs to the numpy C API are moot.We could also just copy/paste the definitions of the functions I need from the
pythoncapi-compat.h
header, but I thought it would be worth taking the project's temperature on adding it as a build-time dependency via a submodule likehighway
andpocketfft
, since there will inevitably be other things we want in the future.The text was updated successfully, but these errors were encountered: