[karandhaodiyal28-hash]

Fixes gh-359.

__array_namespace_info__().dtypes() and .default_dtypes() return np.dtype objects instead of the scalar types:

>>> from array_api_compat import numpy as xp
>>> info = xp.__array_namespace_info__()
>>> info.dtypes()["float64"] == None
True
>>> info.dtypes()["float32"].__name__
AttributeError: 'numpy.dtypes.Float32DType' object has no attribute '__name__'

np.dtype(None) is float64 in NumPy, so float64 is the one dtype that spuriously compares equal to None — a caller that uses None to mean "this dtype is unsupported" gets it backwards for the most important dtype. The missing __name__ hits every dtype.

Both docstrings already show the scalar types, so this brings the code in line with its own documentation. rgommers also suggested returning np.float64 rather than np.dtype('float64') in gh-359, and the cupy/dask backends already return a bare bool for the bool entry, so the scalar type looks like the intended convention here too.

Scope note: cupy/_info.py and dask/array/_info.py have the same pattern, but I've left them untouched — I can only exercise the numpy backend locally.

Changes:

• src/array_api_compat/numpy/_info.py — drop the dtype(...) wrapper in dtypes() and default_dtypes()
• tests/test_numpy.py — regression test (fails before this change, passes after)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[ev-br]

FWIW I agree with #359 (comment):

Changing it now might give some issues for someone in corner cases though, just like this issue is just a corner case. So I don't know if anything should be done here - "just don't do that" is also a fine answer.

The whole equality comparison to None is explicitly called out in PEP8:

Comparisons to singletons like None should always be done with is or is not, never the equality operators.

All in all, this patch fixes what is a borderline user error and has hard-to-predict consequences. Therefore I would prefer to not merge it. Thank you for the patch either way @karandhaodiyal28-hash !