ngoldbaum commented on issue #48473: URL: https://github.com/apache/arrow/issues/48473#issuecomment-5208783651
> Do you mean "cleaner" code-wise? i.e. that it is easier to use numpy 2.0 C API things when requiring numpy 2? I looked at this today and it turns out it should be possible to get StringDType support working while still allowing NumPy 1.26 at runtime. The extra complexity is that to work with StringDType from C++, you'll need to use the [NpyString C API](https://numpy.org/devdocs/reference/c-api/strings.html#npystring-api), which is only available on NumPy 2.0 and newer. If I have NumPy 1.26 installed and I try to import an extension that declares via `NPY_TARGET_VERSION=NPY_2_0_API_VERSION` that it needs to use the NumPy 2.0 C API, I'll see an ImportError at runtime inside of NumPy's C `import_array()` hook. However, only one extension module needs to do this: all of PyArrow extension modules don't need to use the new NumPy C API version. Instead, you could put the things that need the NumPy 2.0 C API into their own extension module that needs NumPy 2.0 or newer at runtime. Then, you could only import that extension after doing the "regular" numpy import and checking NumPy's version to see if NumPy 2.0 is available at runtime. So, not *too bad*, but definitely more complicated than #48473. I pinged the arrow-dev mailing list to see if anyone would be annoyed with dropping runtime support for older NumPy versions. I double-checked and arrow's wheel builds already have a `numpy>=2.0.0` bound in the requirements files and Arrow's CI already explicitly tests against NumPy 1.X at runtime to make sure NumPy's simultaneous backward and forward compatibility trick works in-practice. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
