In my mind, we already have canonical spellings for these and they are:

• np.issubdtype(x.dtype, np.integer)
• np.issubdtype(x.dtype, np.floating)
• np.issubdtype(x.dtype, np.complexfloating)

Perhaps these spellings are too long, but "provide a convenient spelling" is different to "provide a canonical one".

The trouble is that we have extended precision dtypes, and only one of float96 or float128 will actually exist (the other one will raise an AttributeError, also annoying and a frequent source of bugs).

While I would not recommend using this approach of listing the types, the safe spelling is

x.dtype in (np.half, np.single, np.double, np.longdouble)

In my mind, we already have canonical spellings for these and they are

There's a number of issues with that:

• It's not documented as far as I can tell, I'd expect it in https://numpy.org/devdocs/reference/arrays.dtypes.html or on https://numpy.org/devdocs/reference/routines.dtype.html.
• If I check the NumPy and SciPy code bases, both methods I mentioned are used
• If one reads the docstring for np.floating, all it says is "Abstract base class of all floating-point scalar types". So someone familiar with Python would probably try to use isinstance first.
• The issubdtype docstring says "Returns True if first argument is a typecode lower/equal in type hierarchy." which won't make sense to many users, and it's not even clear why one would prefer that over issubsctype given the one-line descriptions.
• Users that want to know "is this an array of floats or integers?" shouldn't have to understand the details of NumPy's dtype hierarchy.

I'm not too interested in arguing about the semantics of "canonical", so let me just say: there is no good way of doing this currently - should we add is_floating, is_complex and is_integer or something similarly named as a sane way of doing this?

My leaning is towards making the documentation much clearer for issubdtype and those abstract classes. We already have an open issue about the various inconsistent pages documenting the scalar types, fixing that would help a fair bit here.

Also, we already have

• iscomplex
• iscomplexobj
• isreal
• isrealobj

IMO, introducing more functions will make things more confusing not less.

Oh yes, that doesn't help, more weird and badly documented functions:(

In [13]: z = np.arange(3, dtype=np.complex64)                              

In [14]: np.iscomplex(z)                                                   
Out[14]: array([False, False, False])

In [15]: np.iscomplexobj(z)                                                
Out[15]: True

In [16]: np.iscomplexobj(z.dtype)   # iscomplexobj docstring: "Check for a complex type ...."                        
Out[16]: False

it's not even clear why one would prefer that over issubsctype given the one-line descriptions.

It looks like this we probably should deprecate one or of the other of these. issubsctype looks weird, because it tries to squash the semantics of isinstance and issubclass into a single function. obj2sctype suffers from the same weirdness.

Deprecating issubsctype sounds like a good idea to me - but then maybe all the other sctype ones as well?

And hide some of the other weird stuff like issubclass_ towards the bottom of the page with some disclaimer, if we don't want to deprecate it?

You can distinguish integers from floating point immediately using np.issubdtype(o, np.inexact)

My mid-term goal would be that we do have an inexact DType, to be just a bit clearer than the np.inexact scalar. np.issubdtype does not check whether it is an "instance" (e.g. array with an inexact dtype or scalar of one).

That does not actually touch np.issubdtype, it rather makes it more precise/extensible.

I do not think we have API equivalent to pythons isinstance, which would be something like:

def is_dtype_instance(obj, DType):
    return isinstance(np.array(obj).dtype, DType)

Admittingly, it currently works with np.issubdtype, but that is only because np.dtype(obj) works if np.dtype(obj.dtype) succeeds.
That is the weird dual use Eric was referring too. np.issubdtype is really equivalent to issubclass.

On a semi related topic, is it possible to enumerate all the inexact types somehow? Is there a list somewhere?

np.typecodes has them in a sense, other than that, probably not unless you want to check __subclasses__()...

Are typecodes that the machine doesn't support eliminated from that list?

There is no such thing as an unsupported type, only aliased names that exist on some but not all platforms.

The very first example from the first post:

x.dtype.kind in np.typecodes["AllFloat"]

is apparently incorrect:

>>> np.array([1,2,3], dtype=np.uint8).dtype.kind in np.typecodes['UnsignedInteger']
False
>>> np.array([1,2,3], dtype=np.uint8).dtype.kind in np.typecodes['AllInteger']
False

It should've been x.dtype.char instead of x.dtype.kind:

>>> np.array([1,2,3], dtype=np.uint8).dtype.char in np.typecodes['UnsignedInteger']
False
>>> np.array([1,2,3], dtype=np.uint8).dtype.char in np.typecodes['AllInteger']
False

Also, bool, str, bytes, object and void dtypes ('?', 'U', 'S', 'O', 'V' accordingly) are missing from the np.typecodes dict (except under the 'All' key).

FWIW, when implementing special functions, I find iscomplexobj to be the most useful interface. That's usually either for determining whether an input dtype needs to be widened for functions mapping reals to complexes,¹ or whether a faster branch can be taken for purely real input.

For 2.0 we deprecated or removed sctype APIs, we cleaned up dtype aliases so there's one canonical name for each dtype with Pythonic and one with C-like names, and we added numpy.isdtype. So I think we addressed this issue to a sufficient extent.

Thanks all!