-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
Providing Public Cython API within NumPy #11803
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
I think this would probably be a good idea. |
Makes sense I think. The Cython wrappers in SciPy have been popular and unproblematic. |
Sounds reasonable, and there is even a start in Should we pin tests to a certain version of cython, or would it be better to test against a range of cython versions (with the associated complications)? |
Doesn't Cython already provide a lot of the NumPy API? https://github.com/cython/cython/blob/master/Cython/Includes/numpy/__init__.pxd |
@bashtage I think this discussion began as cython/cython#2498, and now we need to decide what is easier:
|
It seems totally right to me to have NumPy maintain and ship its own Cython declarations, rather than letting Cython do it. Above all, the C-API that they describe depends on the NumPy version and not on the Cython version, and it's not Cython's decision when and how to deal with additions or incompatible changes. For a migration, Cython already searches the include path before its own standard include directories, so as long as users pass |
This came up again recently in regards to whether certain NumPy functions require the GIL and whether that is reflected correctly in the Cython API. ( cython/cython#2663 ) Side note: Some questions were raised regarding documentation of GIL use in NumPy's C API as well. |
Would it make sense for NumPy to provide
numpy.pxd
andnumpy/math.pxd
(currently included in Cython)?Given NumPy already ships SWIG bindings, providing Cython bindings seems reasonable and is not too different in concept. Plus there are already internal consumers of Cython bindings, which would likely benefit from having access to a single public API. Would add that other projects like SciPy have been adding a fair number of things in
*.pxd
files included in their public API making this a bit of a trend. This would certainly help build a framework for NumPy to expose other things in the public API. Finally would note that having the Cython bindings live in Cython complicates the process of keeping them up-to-date as they must provide support for various versions of NumPy, which should hopefully be less of a problem if Cython bindings were included in NumPy's public API.Thoughts on this would be welcome. :)
The text was updated successfully, but these errors were encountered: