-
Notifications
You must be signed in to change notification settings - Fork 100
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
Support for Numpy 2 #409
Comments
I think if we try to handle the differences between the NumPy versions, then the
I am not sure we need this as long as properly handle the differences for those functions which we do call. (Calling them in unsafe after all, so we can put the responsibility to check the version on the caller.) For the |
I've done a quick test run with NumPy 2.0.0-rc2, and the only thing that breaks for our code base is temporal dtypes. I get a segfault when I try to use those, e.g.:
So using PyArrayDescr can work around that one, but I cannot create an array with temporal types now:
I imagine it's related to this change: Would be great if this could be fixed so that we can support NumPy 2.0.0! |
Sounds reasonable, so we probably need adjust either the FFI definitions or use the wrapper functions in Line 233 in 2170e16
@stinodego Would you be up to submitting a patch? |
I'm afraid I don't have to knowhow to submit a fix, and I don't really have the bandwidth to dive into this right now. |
Hi @stinodego, |
@aMarcireau I tried running my tests with your PR with
I compiled with your branch and had NumPy However, if I leave the default features on, the tests that previously segfaulted now pass with flying colors! So it looks like there's an issue with your NumPy version check, but the implementation works (at least for my code base). |
Thanks for the feedback. I indeed mixed up the conditions for the runtime version check. I just added a commit to the PR that should fix this. |
Hello!
With Numpy 2.0.0rc1 moving closer towards a release, has there been any thought about what will be needed to support the later version or if there's anything needed to make it safer to use in the presence of C API changes? I'm interested in helping with the transition to support both 1.x and 2.x, if useful.
For what it's worth, just naively running the test suite against a local build of Numpy 2 (as of numpy/numpy@182ee60) does pretty well, albeit using the deprecated
numpy.core.multiarray
path over the newnumpy._core.multiarray
. The failures I observed are:--lib
dtype::tests::test_dtype_names
(bool_
is nowbool
)--test array
half_bf16_works
:ml_dtypes
fails to import because it's not ready for Numpy 2copy_to_works
: slot 82PyArray_CopyInto
from_ARRAY_API
is nowNULL
in Numpy 2 so this reliably segfaults (thoughPyArray_CopyInto
got moved into slot 50, so it's still there).Everything else passed for me (macOS 14, Python 3.11, x86_64).
While
copy_to_works
is the only segfault I saw in the test suite, this is the current set of changes in the generated C API capsule between Numpy 1.26.4 and Numpy 2.0.0 (as of numpy/numpy@182ee60), where the number is the offset into thePyArray_API
pointer array:All of the entries in the "removed in" are a place where the slot now has a null pointer, so would segfault if called. Slots 82 and 83 (
PyArray_CopyInto
andPyArray_CopyAnyInto
) got moved into slots 50 and 51 respectively.I've not been following if there were ABI incompatible differences between any functions themselves - I think there was a change from
Py_ssize_t
tointptr_t
(or vice versa) in some, which can be ABI incompatible for some more esoteric platforms.Would an appropriate way of handling most of the removals be to mark those in
impl_array_api
as fallible, and have an explicit non-null pointer check on each access so we can safely panic rather than segfaulting? For the high-level safe API, does something like checking the version on theGILOnceCell
initialisation and saving the result so functions can check andErr
on bad calls work?Happy to help with any implementation, if it'd be useful.
The text was updated successfully, but these errors were encountered: