Open alvarosg opened 1 month ago
the difference here is that npcompat.isdtype
translates the string to a numpy.dtype
superclass, then uses isinstance
to perform the check, while np.isdtype
explicitly raises if it receives anything other than np.dtype
subclasses or the string categories.
I don't think we can do a lot here (correct me if I'm wrong, @shoyer), so it might make more sense to take this up with the numpy
devs.
cc @rgommers, @seberg for awareness
The quick thing is to use np.dtype()
for conversion of the dtype (i.e. also in your code). I suspect np.isdtype
(and other maybe other "array api" function) should do this explicitly.
(I am not sure why it ends up where it ends up with the DType class.)
EDIT: To be clear, since this tries to use array API, I don't know that is possible to work around easily.
for reference, the reason this error is raised is because numpy._core._type_aliases.allTypes
contains a explicit list of allowed dtypes, so any new dtypes that are not in that list – like ml_dtypes.bfloat16
or even the new numpy.dtypes.StringDType
– when passed to numpy.isdtype
will trigger this error.
Which means that wrapping in numpy.dtype
does not help, unfortunately.
contains a explicit list of allowed dtypes
Can you open a NumPy issue about it? I know that there is always this knee jerk reaction to focus on the Array API blessed dtypes only, but honestly, that is just wrong. This is NumPy API and while there may be some guarantees missing, it shouldn't be artificially limiting here.
I have to look at what is going on closer. Maybe using this list was just a case of cargo-culted from the wrong place. Translating arbitrary objects to dtype instances is tricky.
In the meantime, would it make sense to simply continue falling back into the xarray implementationnpcompat.isdtype
, even when np.isdtype
it exists (instead of this try/except)? At the end of the day this is failing at an xarray
callsite.
Can you open a NumPy issue about it?
See numpy/numpy#27545
In the meantime, would it make sense to simply continue falling back into the xarray implementation
npcompat.isdtype
As npcompat
is compatibility code that's supposed to go away as soon as we can require a specific numpy
version I'd prefer waiting until the numpy
team has reached a decision. However, we don't really have to wait until that change in numpy
has been released to write the compat code.
What happened?
Computing the
max
or theisnull
on a DataArray with bfloat16 values raises a:TypeError: dtype argument must be a NumPy dtype, but it is a <class 'numpy.dtype[bfloat16]'>.
This worked fine before updating numpy to version 2. The main difference in the code seems to be that with numpy < 2,
xarray
uses its own implementation ofisdtype
, while for numpy >= 2 it relies onnp.isdtype
. This is confirmed by checking that doingimport numpy as np; del np.isdtype
fixes the problem.What did you expect to happen?
I expected the computation to be successful, just as prior to numpy 2.
Minimal Complete Verifiable Example
MVCE confirmation
Relevant log output
Anything else we need to know?
Here's a a different reproducer showing the inconsistency between
np.isdtype
andnpcompat.isdtype
Environment