The defition of the <X>Like aliases is currently based on whether or not the scalar-type can be cast into <X> (assuming casting="same_kind"), so the assumption here is more or less that the value will be fed to np.arrray() or an equivalent.

Obviously this means that _IntLike is not always a good fit for every situation, especially when indexing is in concerned with np.bool_.__index__ being deprecated.
In the latter situation I'd just stick to something akin to Union[int, np.integer], or if the situation allows for it: the typing.SupportsIndex protocol.

As a side note, mypy already considers complex a super-type of float (same as for float and int).
So if one is interested in accepting the former but rejecting the latter they would have to explicitly add a float-based overload returning NoReturn:

from typing import overload, NoReturn

@overload 
def func(a: complex) -> complex: ...
@overload 
def func(a: float) -> NoReturn: ...

The defition of the <X>Like aliases is currently based on whether or not the scalar-type can be cast into <X> (assuming casting="same_kind"), so the assumption here is more or less that the value will be fed to np.arrray() or an equivalent.

I can't think of many situations where I'd want to use this though. NumPy itself is fairly inconsistent, e.g.:

In [1]: x = np.array([True, False])

In [2]: np.sin(x)
Out[2]: array([0.8413, 0.    ], dtype=float16)

In [3]: np.add(x, x)  # hard to guess if this will upcast or not without trying
Out[3]: array([ True, False])

In [4]: np.add.reduce(x, x)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-8a94aae9244a> in <module>
----> 1 np.add.reduce(x, x)

TypeError: only integer scalar arrays can be converted to a scalar index

In [5]: np.sum(x)
Out[5]: 1

In [6]: np.add(x, [1, 2])
Out[6]: array([2, 2])

In [7]: np.subtract(x, x)  # This reasoning makes little sense, no one really means bitwise_xor
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-7-294a82b71bf3> in <module>
----> 1 np.subtract(x, x)

TypeError: numpy boolean subtract, the `-` operator, is not supported, use the bitwise_xor, the `^` operator, or the logical_xor function instead.

I'd like all of that to consistently error where it casts to integer now. Which is not something we can easily do - but if we're going to expose an alias in numpy.typing as public API, why not make it the thing people should be using for new code when working with integers?

This is why I asked data-apis/array-api#101 (comment) and data-apis/array-api#101 (comment).

Which is not something we can easily do - but if we're going to expose an alias in numpy.typing as public API, why not make it the thing people should be using for new code when working with integers?

@rgommers If the plan is to expose them then I'd definitely agree with you.

The current aliases are IMO too useful to remove in their entirety, so instead I'd propose to just give them a more apropiate. Perhaps something along the lines of _IntLike_co and _FloatLike_co (the same holds for _ArrayLike<X>)?

_co sounds good to me.