Thanks @BvB93, this sounds like a good idea.

the latter also containing a number of platform specifics in the case of np.number subclasses.

I'm actually failing to spot the platform-specific bit. E.g. a common type of dynamic check like is_32_bit = np.intp(0).itemsize < 8. What am I overlooking?

I'm actually failing to spot the platform-specific bit. E.g. a common type of dynamic check like is_32_bit = np.intp(0).itemsize < 8. What am I overlooking?

They keyword here is "dynamic". The example you provided works just fine during runtime, but for static
type checking it has to be, well, defined statically. The latter is somewhat tricky if its type (or value)
is platform specific, hence this PR.

As a side note, the CI failures suggest that there are still some problems with the current implementation;
I'll take a closer look at it tomorrow.

Converting this into a draft for now, as there are still some issues getting the tests running properly.

I think it would be worth a detailed explanation somewhat about exactly what is going on with the aliases:

Good point, I'll update the PR description in a bit.

the typing stubs are written as if the sized types are the native ones

To be fair, this is consist with how the number subclasses are treated during runtime
(at least on the python side), where their C names are treated as aliases for their corresponding
sized type rather than the other way around.

In [2]: np.byte
Out[2]: numpy.int8

the reverse aliases are not quite accurate - they suggest that two of intc, int_, longlong are identical, when in fact there are distinct scalar types

I'm not quite sure how you arrived at this conclusion, as can be seen below the only two integer types
which are considered identical by definition are intp and int0.

https://github.com/numpy/numpy/blob/e6a5514cae950f9336866ac39b4880f8b80bcce0/tools/generate_type_hints.py#L138-L143

Running the script locally yields the following output (MacOS):

byte = int8
short = int16
intc = int32
intp = int0 = int64
int_ = int64
longlong = Any

Running the script locally yields the following output (MacOS):

byte = int8
short = int16
intc = int32
intp = int0 = int64
int_ = int64
longlong = Any

Ah, I wasn't aware that longlong = Any was the result of this script.

Ah, I wasn't aware that longlong = Any was the result of this script.

Yes, Any is used as a fallback value here in case the aliased typed is still unannotated (or if it isn't an alias at all!).

So I'm having some trouble to get this working with the likes of pip install -V . (as is done in the tests).

The part I'm struggling with is accessing the content of np.core ("Importing the numpy C-extensions failed")
in order to resolve the aliases of all the np.generic subclasses. I suspect that I'll have to hook into np.distutils
somewhere to get this working, but I'm not familiar enough with the whole setup process to narrow it down any further.

Could anyone provide some more insight here?

Xref #16548 as this issue describes more or less what this PR is doing.

Say, aren't the numerical scalars in ctypes always of the same size as their np.number-based counterpart?
If so, then the problem with importing from np.core (#17514 (comment)) can be circumvented by grabbing the scalar sizes from ctypes instead of numpy.

Any thoughts?

Rebased to get rid of a merge conflict.

Just out of curiosity - wouldn't it be easier to implement a small mypy plugin that transforms some types depending on the current platform?

Just out of curiosity - wouldn't it be easier to implement a small mypy plugin that transforms some types depending on the current platform?

In principle we could do this with the help of get_type_analyze_hook if we structure the types/type-aliases as following.
This does mean the users will have to enable the plugin in their mypy config files though.

from typing import Any, Annotated, Union, Literal
import numpy as np
import numpy.typing as npt

_Int64CodesBase = Literal['i8', ...]
_LongLongCodes = Literal['q', ...]
_IntPCodes = Literal['p', ...]

# A plugin can append the union with charcodes from `np.longlong`, `np.intp`, etc
_Int64Codes = Annotated[Union[_Int64CodesBase], "_Int64Codes"]

# A plugin can transform this into `intp = signedinteger[npt._64Bit]`
class intp(np.singedinteger[Any]): ...  

Personally I'd okay with either option, though going the plugin route does mean we'll have expose it to public API.
I suspect the latter will be inevitable however, at last at some point in the future.

After a bit of trial and error I managed to get the plugin-based approach working.
The respective PR is up at #17843.

Closed in favor of #17843.