DEP: Remove deprecated numeric style dtype strings

[NectDz]

See #18993
This issue was presented by @Daybreak2019

When the function strncmp was used it did not account for a null byte character meaning it is an incomplete comparison.

The elements in the array dep_tps on line 1727 in the descriptor.c file did not match the elements in the deprecated_types array in test_deprecations.py line 324 therefore a change in the dep_tps array had to be made so the null byte character could be compared correctly.

The null byte character is compared on line 1732 in the descriptor.c file by the change strlen(dep_tp)+1 which includes the strings length but adds +1 so the null byte character can also be compared making the strncmp function compare both strings completely.

[seberg]

Thanks, would be fine to just put this in. But... if you are to it, now that I see the deprecation comment: it would be much nicer to finish the deprecation and delete the whole branch as was started in gh-16554.

The code effectively always did the right thing, the warnings were given. The typical timelin for deprecation is one year/two releases, which the next release will be. And there is no reason to delay in this specific case.

[eric-wieser]

Is this code even reachable? I can't work out how to trigger the warning.

[seberg]

Use the exact string as dtype: np.dtype("Uint64"), etc. it is a bit confusing, because pre 1.20 deprecated a whole bunch of other ones, and 1.20+ has only a few of these remaining. EDIT: And they are missing on <1.20, so you can't reproduce it there.

[eric-wieser]

I'm trying this out on 1.19.4 and getting no warning - is the deprecation more recent than that? edit: yes.

[NectDz]

Thanks, would be fine to just put this in. But... if you are to it, now that I see the deprecation comment: it would be much nicer to finish the deprecation and delete the whole branch as was started in gh-16554.

The code effectively always did the right thing, the warnings were given. The typical timelin for deprecation is one year/two releases, which the next release will be. And there is no reason to delay in this specific case.

Thanks for the feedback! Based on your linked PR, here are the things I think I have to do. Does this make sense / is anything missing from my list?

1. Remove 32 and 64 from the arrays in the _type_aliases.py file on lines 212 and 213
2. Remove uint32 and uint64 in the numerictypes.py file on line 127
3. Remove uint32 and uint64 in the test_deprecations.py file on line 627

[seberg]

Remove 32 and 64 from the arrays in the _type_aliases.py file on lines 212 and 213

No, I think those are fine, note that the main problem here is the capital letter, uint32 is fine, but Uint32 is not.

Remove uint32 and uint64 in the numerictypes.py file on line 127

Yeah, that looks right.

Remove uint32 and uint64 in the test_deprecations.py file on line 627

You should delete the whole TestNumericStyleTypecodes testcase/class. Then add all of them to the test_numeric_style_types_are_invalid test in numpy/core/tests/test_dtype.py

[seberg]

Thanks for doing the more complete fix! Just two small things also to make the linting CI happy. It would be nice to have a very brief (single bullet point) release note for this. doc/release/upcoming_changes/README.rst explains how to do this. Just to note that the deprecation is finalized.

But basically, this is good to go :).

[NectDz]

Thanks for doing the more complete fix! Just two small things also to make the linting CI happy. It would be nice to have a very brief (single bullet point) release note for this. doc/release/upcoming_changes/README.rst explains how to do this. Just to note that the deprecation is finalized.

But basically, this is good to go :).

I am currently doing the release note and I am wondering on what PR type I should list this as?

[seberg]

It would be expired.

[NectDz]

hmm, do you have any idea on why the test is failing @seberg ? I don't know what is going wrong

[seberg]

Those unfortunately are flaky, don't worry about them. The changes are all good I think. I would modify the release note to something like:

* Using the strings ``"Bytes0"``, <???>, and <???> as a dtype will now raise a ``TypeError``.

np.Bytes0, etc. never actually existed. (I had intended to just do that and merge, but forgot if you want to update the release note please do. Mostly to use the strings, maybe shorten it a bit, and use a bullet point. If it spans multiple lines, you have to indent the second line, I think.)

[NectDz]

Those unfortunately are flaky, don't worry about them. The changes are all good I think. I would modify the release note to something like:

* Using the strings ``"Bytes0"``, <???>, and <???> as a dtype will now raise a ``TypeError``.

np.Bytes0, etc. never actually existed. (I had intended to just do that and merge, but forgot if you want to update the release note please do. Mostly to use the strings, maybe shorten it a bit, and use a bullet point. If it spans multiple lines, you have to indent the second line, I think.)

ok sounds good but just to clear things up, would I also have to include Uint32 and Uint64 as strings in the release note?

[seberg]

Yeah, I think listing them all makes sense, it is not that long of a list.

[seberg]

Cancelled the last job, I suspect things were just slow due to the github issues today. In effect, all jobs have run with only style change differences anyway.

Thanks @NectDz, especially for taking the time to finish the deprecation when the issue was just about the smaller fix!