Hi @seberg,

I've got two questions regarding remaining checks that failed:

1. Should I drop np.float128 and np.complex256 usages and replace them with (c)longdouble? The new implementation of _type_aliases.py doesn't build these entries for allTypes as it only imports names from typeinfo.
2. I'm wondering how to solve one last C dependency that causes tests to break. The numpy/f2py/tests/test_array_from_pyobj.py needs to know the C name of a given dtype here as it uses C name to import a dtype from f2py extension. Previously it worked because typeinfo was a dict with C names as keys and dtypes as values.
   As in the current implementation typeinfos keys are already proper Python names I have no way to determine "C" name to use to call "wrap" f2py extension with (line 219 is the one where assert fails).
   Is there another way to get C type name -> Python dtype mapping to use for this test? (It looks like the mapping that we intentionally removed from typeinfo in this PR).

Hmmm, I thought this was already being pushed forward/through, while I was out.

Should I drop np.float128 and np.complex256 usages and replace them with (c)longdouble? The new implementation of _type_aliases.py doesn't build these entries for allTypes as it only imports names from typeinfo.

Just use .itemsize to define float{...} if the itemsize is 96 or 128, and the same for clongdouble? I think we should at least add a warning on those names, but that is a distinct issue.

I'm wondering how to solve one last C dependency that causes tests to break

I guess we could add the NPY_INT, etc. names to the dictionary, additionally, or a different dictionary. In general, I don't mind the approach taken here to just have another dict, especially in tests where it isn't as bad to duplicate things.

I would really like this to move forward, because I started looking into changing the definition for intp, which means changing a character code here or there probably. So there are likely conflicts.

@seberg Thank you for feedback! For now I will include these extended precision sized aliases based on .itemsize.
I think that additional dict built on C side that defines C names mapped to dtypes (to be used in tests) solves this issue.

Hi @seberg,

I pushed a new commit - here are my comments:

1. I added C's NPY_* names that are used in f2py tests to get the cname -> dtype mapping that was missing.
2. I named it c_names_dict, is it fine, or would you prefer a different name?
3. I added extended precision sized aliases as we discussed (np.float128, np.complex256 etc.).
4. The PR is ready from my side. One question: I see that 6 CI stages are missing - all azure-pipelines - do you know why? (it would be better to see them passing as well here)

I don't know why it is not showing up in the summary, but there is a test failure on azure.

I don't know why it is not showing up in the summary, but there is a test failure on azure.

Huh, the link you provided is from different PR (core to _core rename), not this one.
Maybe I can just retrigger.

Ok, now azure stages are running - CI is green.

I added extended precision sized aliases as we discussed

Are you OK making the bitsized longdouble aliases generate deprecation warnings in a followup?

Are you OK making the bitsized longdouble aliases generate deprecation warnings in a followup?

Are you asking me or @mtsokol, TBH, whether or not we do it, it is nice as a follow-up any case. It might be good if someone other than me can have a quick look as I wrote the C changes. I didn't have a close look yet (or at least recently), but I suspect the changes are fine.

I was asking Mateusz since that was the only ask in the reviews that wasn't addressed. Thanks for the context though.

I looked over the C changes earlier and didn't see any issues. I'll give them another once-over before merging.

Sure! I will deprecate these aliases in the next PR.

It appears this removed some previously public working aliases in np.dtype. Is this expected?

In [1]: import numpy as np

In [2]: np.dtype("unicode")
Out[2]: dtype('<U')

In [3]: np.__version__
Out[3]: '1.24.4'

>>> import numpy as np
>>> np.dtype("unicode")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: data type 'unicode' not understood
>>> np.__version__
'2.0.0.dev0+git20231007.040ed2d'

I think that was missed, can you open an issue?

unicode was defined as an extra-alias and didn't come from the C layer. I think this and one more thing are missing after refactor - let me readd it!

Here's an issue: #24892