DEP,BUG: Finalize subarray dtype FutureWarning and fix its assignment #23666
Conversation
In some cases we know that we want to use the *exact* dtype that we already have (mainly when taking views). This is also useful internally because there are very rare code-paths were we even create temporary arrays that contain subarray dtypes.
This is now OK to just support, we won't replace things and things should work out for the most part (probably).
This unfortunately switches over the C-only path when FromArray is called with a subarray dtype. Together with the previous commit (which is very simple but in a sense does the heavy lifting): Closes numpygh-23083
seberg
force-pushed
the
subarray-cleanup
branch
from
53f64f2 to
1d4f1ac
Compare
| } | ||
| else { | ||
| nbytes = descr->elsize = sizeof(npy_ucs4); | ||
| } |
There was a problem hiding this comment.
This whole change is just one indentation level.
There was a problem hiding this comment.
This looks like a good cleanup! I agree the new enum is much clearer than the old boolean flags at the end of PyArray_NewFromDescr_int's signature.
I only looked carefully at the structural changes to that function since I was working there recently and didn't look closely at the behavior changes that finalizing the deprecations leads to.
| PyArray_FLAGS(self), | ||
| ensure_array ? NULL : (PyObject *)self, | ||
| (PyObject *)self); | ||
| (PyObject *)self, _NPY_ARRAY_ENSURE_DTYPE_IDENTITY); |
|
Thanks @seberg. This is a nice cleanup and refactor of a clunky interface |
|
Thanks for the review. This was started a bit ago, so I will note it but I really don't think we should worry: I think there is one code path were the deprecation was missing. That code-path should do complete and utter nonsense though (due to the way broadcasting works), which is why I want to just not worry about it. (A new |
This PR should be reviewed in multiple steps, because I included a first commit which is pretty simple, but an important refactor:
PyArray_NewFromDescr_intto use a flags object as a last thing (because I didn't want to pass 3 flags). It then adds a third flag which denotes that we know the dtype is good. That flag is generally only considered valid for creating a view, but for those it makes a lot of sense (and implies/side-steps the S0 allowing flag, which we still need, but is probably more of a stop-gap).ufunc.resolve_dtypesdtype=is given in array or astype calls, that cast was previously performed after absorbing subarray dimensions in some code paths. This is not the case anymore now.As mentioned in the commit message. The combination of the two commits not only expires the FutureWarning, it also closes gh-23083.