Repository navigation
ENH: numpy.isdtype with custom dtypes #27545
Description
Proposed new feature or change:
The implementation of numpy.isdtype currently checks against an explicit list of kind names, and another one of dtypes (numpy._core._type_aliases.allTypes), and raises for all other objects. While the description of the exception ("dtype argument must be a NumPy dtype") makes sense for for dtypes created for other array API implementing types, I don't think this is the case for custom numpy dtypes which are explicitly written for numpy.
Incidentally, checking the new StringDType also raises on numpy=2.1.1 (and as far as I can tell would even fail on current main):
In [1]: import numpy as np
...:
...: np.isdtype(np.dtypes.StringDType(), "real floating")
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
Cell In[1], line 3
1 import numpy as np
----> 3 np.isdtype(np.dtypes.StringDType(), "real floating")
File .../numpy/_core/numerictypes.py:425, in isdtype(dtype, kind)
423 dtype = _preprocess_dtype(dtype)
424 except _PreprocessDTypeError:
--> 425 raise TypeError(
426 "dtype argument must be a NumPy dtype, "
427 f"but it is a {type(dtype)}."
428 ) from None
430 input_kinds = kind if isinstance(kind, tuple) else (kind,)
432 processed_kinds = set()
TypeError: dtype argument must be a NumPy dtype, but it is a <class 'numpy.dtypes.StringDType'>.This came up in pydata/xarray#9568, where someone wanted to use xarray with the dtypes defined by ml_types, which eventually failed because of the numpy.isdtype call.
So my question is: should numpy.isdtype support checking custom numpy dtypes? And if so, should it always return False, or do we need some kind of mechanism to include custom dtypes in the categories defined by the kind names?
(while I classified this as an enhancement, I could also see this as a bug)
Activity
seberg commentedon Oct 14, 2024
Yes this should definitely work (or at least not fail the way it does). There is the caveat that making sure that
bfloat16passes the"real floating"check may need a bit of work/fixes.Vednawale commentedon Oct 18, 2024
mtsokol commentedon Jan 16, 2025
I think that then we would need a
kindattibute for dtypes to know to which kind the dtype belongs to (and for user-defined dtypes the user also needs to provide akind, following Array API taxonomy).ilan-gold commentedon Dec 23, 2025
+1 Running into the same issue, this time with moving to use the array api +
StringDtype. I think this is definitely a bug given the error message.[-]ENH: `numpy.isdtype` with custom dtypes[/-][+]ENH: `numpy.isdtype` with StringDtype[/+][-]ENH: `numpy.isdtype` with StringDtype[/-][+]ENH: `numpy.isdtype` with custom dtypes[/+]ngoldbaum commentedon Jul 17, 2026
Hi all, sorry for letting this sit for so long. I completely missed it when it was filed in 2024. I'm working on a fix.