This isn't right unfortunately (i.e. on windows this is q). The literal code for Int64 is l or q and the type number 7 or 9 (I guess). Type numbers are fixed for the C names, not the names here.
The mypy plugin is supposed to sort this out I think: https://github.com/numpy/numpy/blob/main/numpy/typing/mypy_plugin.py

Now, maybe that plugin is the wrong approach here, though. In principle, the built-time information we need is:

• Is int32 an int or a long?
• Is int64 an long or a longlong
• What is the size of longdouble?

Additionally, even if inferable, one of those integers is always equivalent to both. One day, I would like to encode that by making the C named version a subclass of the bit-sized one. Or, by making it an alias only so that the type-number is an instance property only (i.e. the Int64 dtype instances can still be either long or longlong with their old type numbers, but they behave identical, so only have a single type. Without a subclass the small oddity one would have to accept is that LongLong() might not return the type-code we want).

My gut feeling now is that this would be much better than what we have. So if we have some cycles/will to clean it up, I might suggest:

• Creating a new templated stub file with the crucial information (might be this file itself).
• Ask @ngoldbaum to help with the meson tooling to fill in the blanks at compile time (need to use compile time constants/sizes to correctly cross-compile).

This isn't right unfortunately (i.e. on windows this is q). The literal code for Int64 is l or q and the type number 7 or 9 (I guess).
Type numbers are fixed for the C names, not the names here.

Ah ok that makes sense. The reason I was confused is because e.g. numpy.dtypes.ByteDType is a direct alias for Int8DType, instead of the other way around. But in hindsight the fact that Int8DType().char is 'b', instead of 'i1', should've been a giveaway.

The mypy plugin is supposed to sort this out I think

I don't consider the mypy plugin as a solution myself, since there are more (and imo better) fish in the typing sea, e.g. pyright.
It's not that I'm against a mypy plugin per-se, but I think that prioritizing a type-checker-agnostic solution should be our aim.

And I'm also not really sure if platform-dependent types is a good idea in general actually.
Having your type stubs depend on e.g. Python version or NumPy version is no problem I think, as these are explicitly known beforehand, and are within the control of the user.
But platform-dependent type stubs are a different story, and could lead to those "but it works on my machine" scenario's, which could lead to 3rd party libraries that are only type-valid on x86/64 win32 machines that compiled numpy with the default compilation options (unless it's the 3rd full moon of a prime-numbered year obviously).

So that's why I want to at least cover all the possible typecodes and sizes here, so that it's platform-agnostic.
But on the other hand, I don't think it's a good idea to account for all theoretically possible situations, assuming that the system is e.g. either 32 or 64 bits, that the C99 standards apply, and that byte, short, and intc are 8, 16, and 32 bits (as I was told that theoretically they can be bigger, but that in practice this almost never is the case, but correct me if I'm wrong; I don't have much C experience).

Having platform-agnostic stubs could also help developers find platform-dependent bugs more easily. Type-checkers will then be able to detect incorrect assumptions such as e.g. being able to cast a long to int32 in safe mode.

And while I think that generating stubs as build-time are definitely a better approach than the mypy-plugin one, the platform-agnostic stubs would still have my preference.

What do you think @seberg?

🤷, dunno. You will lose some round-tripping, since you will lose the ability to distinguish int64 and int32 when it comes to typecodes and chars. And that means in some cases things cannot round-trip (like np.dtype(int_dtype.char), or with the struct.pack module).

OTOH, yes, maybe it helps someone somewhere to clarify that if you write long you may get a 32bit or 64bit integer.
I suppose you can only try and see how many things get annoyed. Avoiding a plugin seems easy, but removing runtime sizes, I don't know.

Can't the unit be part of the class? Just like the byteorder.

Also, for the byte-order shouldn't that refer to the order in the class definition? (But maybe the overloads become too long for it to be useful right now.)

Can't the unit be part of the class? Just like the byteorder.

Yea that's probably better. It's not really doing anything useful at the moment, and is mostly there for aesthetics.

Also, for the byte-order shouldn't that refer to the order in the class definition?

Perhaps it should, but the only way I can think of to make that work, would be to add a byteorder type parameter, and add 28+ overloads in __new__ (at least 2 for each unit).
But that might be a bit too messy, compared to the advantages.
... or isn't that what you mean?

That was what I meant... Anyway, since this is just about the DType classes as exposed here, let's not worry about it too much. All of this might become more relvant when the classes are properly merged...