DEP: Deprecate data_type.dtype if attribute is not already a dtype
#13578
Conversation
66aab05 to
0d7b8ed
Compare
d0c7b4e to
28da717
Compare
|
A question: is it the plan to (eventually) move forward with this PR or is that still undecided? |
|
Not sure why it stalled, unless anyone knows of a user who expects |
| "`np.dtype(data_type.dtype)`. This will raise an error " | ||
| "in NumPy 1.19.") < 0) { | ||
| /* NumPy 1.19, 2020-02-07 */ |
There was a problem hiding this comment.
| "`np.dtype(data_type.dtype)`. This will raise an error " | |
| "in NumPy 1.19.") < 0) { | |
| /* NumPy 1.19, 2020-02-07 */ | |
| "`np.dtype(data_type.dtype)`.") < 0) { | |
| /* NumPy 1.20, 2020-10-19 */ |
|
IMO it seems like a reasonable change and it makes typing a bit easier, so +1. |
ff5686c to
1c8e1e4
Compare
|
hmm. The circelCI merge-before-build command seems to be causing problems. Maybe we should allow it to fail silently. |
|
The deprecation warning is leaking out into tests |
|
@BvB93 its a new typing test that is failing (and not running locally with the slow flag). Should the test be modified or catch the warning? |
Ah yes, the numpy/numpy/typing/tests/data/pass/dtype.py Lines 31 to 32 in 136185c |
|
Thanks! Just wasn't sure which direction to fix it best. |
|
@mattip I think the circleci is probably only because I had it set up on my branch. Disabled it now, it is not something I use regularly anyway. |
| array, alltrue, ndarray, zeros, dtype, intp, clongdouble | ||
| ) | ||
| import numpy as np | ||
|
|
There was a problem hiding this comment.
Is this change required to avoid the deprecation warning? Does that mean all user code must now change?
There was a problem hiding this comment.
No, don't remember why I did it here, but it is just maintanence, there must have been an issue with dtype being overshadowed somewhere.
After the deprecation, a recursive lookup for `.dtype` will not be possible, since `.dtype` has to be a dtype instance.
2173a20 to
92275af
Compare
|
Could you move the deprecation test to the proper file? Otherwise this looks good to me. |
92275af to
97eab33
Compare
|
Done, we could consider deprecating even more, but I guess this might be a good (and easy) first step. Yeah, I think I first wrote that at a time when I was considering to stop relying on that file so much (The original reason, and most of the magic in that file, was to work around python issues with warnings, which were eventually fixed). |
|
Thanks @seberg |
…; not arbitrary dtype-like objects xref numpy#13578
|
@seberg I notice that this created |
|
Oh wow, that is a while ago. Yeah wrong place, should have been part of the release notes... |
|
OK, I'll make a PR to get rid of it in main and take care of it in the 1.21.x branch. |
Followup from gh-13003,
marking as draft because that one needs to be merged (and then this one rebased) before it can go in.This could hit the mailing list, but I think the deprecation here should be pretty uncontroversial, since it only enforces that
something.dtypereturns a dtype in statements such asnp.dtype(something). It does not actually force the user to write the.dtypeyet.