That's a very useful analysis and clear table, thanks @mtsokol. I think what may be useful for added insight here is explicitly listing all the names for the first two rows. I'd name those "canonical names for C types" and "canonical names in Python". There will be some adjustments here already, e.g. the actual C name float is what I'd expect us to call np.single. Something like (add complex types, str/object/intp/etc. too):

allTypes doesn't seem to be public, so I'm not sure we should focus on it in the first instance.

Sure! I included such table and I filled it with values coming from sctypeDict. Both columns are present in the dictionary (so all names can be used in python code) but they should clarify relationships between specific names.

allTypes is here to help understand how proposed implementation works (the refactored file builds allTypes and sctypeDict at the same time, as original version).

Sorry, maybe I should have suggested 3 columns. What I meant was the Python "C-like" and "Pythonic" names. The actual type in C could be useful too. So for this one for example:

int (only in C) | int32 / intc
-- | --

in Python code we'd prefer if people wrote np.int32. And the "C-like" name we also want to keep is intc. And any other aliases are on the list for removal.

The long/int64 one doesn't look quite correct. It's longlong in Python I believe as the "C-like" alias.

intp/uintp should be separate entries probably.

I updated the 2nd table with three columns ("Canonical Python", "C-like python", "compatible C type") - I wanted to clarify some rows.

The long/int64 one doesn't look quite correct. It's longlong in Python I believe as the "C-like" alias.

As int / long / longlong Python counterparts may vary depending on architecture, I checked mappings on my machine (Darwin x86_64) and Emscripten wasm32, and added all combinations that I found with / in these rows. WDYT?

intp/uintp should be separate entries probably.

Sure! Moved to separate rows.

As int / long / longlong Python counterparts may vary depending on architecture, I checked mappings on my machine (Darwin x86_64) and Emscripten wasm32, and added all combinations that I found with / in these rows. WDYT?

I think I'd write it like this:

So for C types that vary in size are exposed in the Python API, we don't have a canonical sized alias, and there should be one preferred name only. So C int becomes intc (or int_, but I think intc would be preferred), and C long becomes intp. I admit I don't know why we don't have a np.long or np.long_.

I think I'd write it like this:
Canonical Python API name Python API "C-like" name Actual C type
intc int
uintc unsigned int
intp ? long

So for C types that vary in size are exposed in the Python API, we don't have a canonical sized alias, and there should be one preferred name only. So C int becomes intc (or int_, but I think intc would be preferred), and C long becomes intp. I admit I don't know why we don't have a np.long or np.long_.

I updated the table so there are no multiple options depending on architecture (thus int_ is not in the table).

Getting there! Still some more to do for integers I think. What I'd like to get to is for each row to be unique. C int / long / longlong are separate types, so they should never be on the same row. I think the situation is:

• Python name int32 corresponding to C-like name intc and C type int (well, the latter is technically not true - https://stackoverflow.com/questions/14515874/difference-between-int32-int-int32-t-int8-and-int8-t - but in a practical sense it always is true I believe)
• same for int64 and longlong, C type long long
• there is no fixed-size equivalent for long; that is intp

Getting there! Still some more to do for integers I think. What I'd like to get to is for each row to be unique. C int / long / longlong are separate types, so they should never be on the same row. I think the situation is: ...

My previous update accidentally didn't get saved - I updated the table one more time. It should finally have unique values in each cell.

This looks quite good to me now, thanks Mateusz. Last thoughts for now:

• we need to add bool as the canonical Python name, and keep bool_ as an alias because np.bool does not exist in 1.25.x/1.26.x
• the C types for complex types can be added: complex float, complex double, and complex long double,

Closing as #24651 has been opened to hide outdated comments.