The.view() method sets the dtype and this is a bit hard to handle. InPyArray_View (seeconvert.c) first a new array is constructed withPyArray_NewFromDescr_int and then the dtype is updated withPyObject_SetAttrString. I replaced the call toPyObject_SetAttrString with a direct call to the code updating the dtype, bypassing the deprecation warning. This works fine for exact arrays, but gives issues for subclasses, in particular the masked array.

We could usePyObject_SetAttrString insidePyArray_View and catch the generated deprecation warning. This would hide changing the dtype inPyArray_View (but it is ok, there is only a single reference to the array), but users changing the dtype from python will get the deprecation warning.

Any other ideas on how to approach this?

Update: refactored the PR to use unique references for warning. This will exclude the calls from insidePyArray_View.

Any other ideas on how to approach this?
Update: refactored the PR to use unique references for warning. This will exclude the calls from inside PyArray_View.

Unique reference cheeck seems OK to me, also just to be nice for a bit. Overall, I think there is no reason not to pass thedtype already while creating the initial view (that currently has the same dtype), but not quite sure how that pans out.
My first guess would be that the only reason for this organization is thatarr.dtype = includes the necessary checks for whether a view is OK.

As for some newer code changes here, let's avoid any warning filtering (yes I guess on new Python it's threadsafe at least, but...). Either, this still works fine now that you did the refcount check, or we should just use aarr.view() which could be guarded bydtype != dtype.

(I am not certain the refcount checks will work on PyPy as is, so there might be a problem with using it for avoiding thview() change.)

As for some newer code changes here, let's avoid any warning filtering (yes I guess on new Python it's threadsafe at least, but...). Either, this still works fine now that you did the refcount check, or we should just use aarr.view() which could be guarded bydtype != dtype.

The warning filtering is indeed not nice. But using a view won't work directly. For example for the recarray the dtype is updated in the array finalizer.

I can create a view with the new dtype (maybe this will create an infinite recursion, I will have to try), but I cannot replace self with the new view.

but I cannot replace self with the new view.

Right, this was maybe the reason for why it wasn't deprecated before. I think we need a solution for it, though. And as much as I dislike this record array stuff and we should maybe discourage its use.

My first thought is one or both of:

• Allow this specific change for record-arrays, where the new dtype is known to be fully equivalent and behave exactly the same.
• Just add a by-pass, with something_dtype = setting, or a (semi?)private function that forces it. (I slightly fear that_dtype might be used, so maybe something more awkward.)

Unless the "unique reference" path can fix this (but I guess it didn't).

The point is, if our code needs a warning manager, then we are just kicking the real solution down the road, since eventually that should be an error and the warning context manager will stop working anyway.

but I cannot replace self with the new view.

Right, this was maybe the reason for why it wasn't deprecated before. I think we need a solution for it, though. And as much as I dislike this record array stuff and we should maybe discourage its use.

My first thought is one or both of:

• Allow this specific change for record-arrays, where the new dtype is known to be fully equivalent and behave exactly the same.

Do you means checking inside the dtype setter whether the object is a subclass of masked array or recarray? That is possible (a bit inconvenient as the masked array and rec array are defined in python).

• Just add a by-pass, with something_dtype = setting, or a (semi?)private function that forces it. (I slightly fear that_dtype might be used, so maybe something more awkward.)

This seems a reasonable approach. Any user making use of_dtype would be aware this is an internal method and best avoided.

It would be much nicer if we could rewrite the code for masked array and recarray to not update the dtype at all. If we are not able to do this, then perhaps there are users with their own subclasses that will face the same issues. For masked array the most changes are introduced in#10314 and#5943.@ahaldane@mhvk do you know whether avoiding setting the dtype in the finalizer would be possible?

Unless the "unique reference" path can fix this (but I guess it didn't).

The unique reference path does not help here, at the point where the recarray or masked array sets the dtype, we already have 5 references to the object.

The point is, if our code needs a warning manager, then we are just kicking the real solution down the road, since eventually that should be an error and the warning context manager will stop working anyway.

Kicking down the solution might be ok at first. This PR is to signal users we are deprecating setting thedtype andstrides. We can adapt our own code in a followup PR.

Do you means checking inside the dtype setter whether the object is a subclass of masked array or recarray?

I was thinking forrecord dtypes, you could check that the only difference in the dtype is indeed that it's a "record" one. (I don't quite recall what that meant, it's an annoying concept that exists solely to return different scalars, IIRC.)

It would be nice to just not need any of this and a great improvement to try and do something about it. But it might be a rather deep rabbit hole...

Kicking down the solution might be ok at first. This PR is to signal users we are deprecating setting the dtype and strides. We can adapt our own code in a followup PR.

Yeah it may be fine. It would be nice not to if it isn't hard, for three reasons (none of which are quite blocking maybe):

1. Doing it know gives us full confidence we can go through with it.
2. Whatever work-around we add may be useful/needed by downstream. Which makes life easier for them (worst case they need one version dependent set of code, not update that again).
3. Warning context managers are not very fast and not thread safe on older Python versions.

It would be much nicer if we could rewrite the code for masked array and recarray to not update the dtype at all.

Yes, but especially for record arrays it may be a rather deep rabbit hole as mentioned above.

Darn, what a rabbit hole indeed! One possible solution is to start giving the warning only onndarray itself instead of also on subclasses - then we do not need any changes to masked and record arrays. I.e.,

--- a/numpy/_core/src/multiarray/getset.c+++ b/numpy/_core/src/multiarray/getset.c@@ -527,9 +527,7 @@ static int array_descr_set(PyArrayObject *self, PyObject *arg, void *NPY_UNUSED(ignored)) {     // to be replaced with PyUnstable_Object_IsUniquelyReferenced https://github.com/python/cpython/pull/133144-    int unique_reference = (Py_REFCNT(self) == 1);--    if (!unique_reference) {+    if (PyArray_CheckExact(self) && (Py_REFCNT(self) != 1)) {         // this will not emit deprecation warnings for all cases, but for most it will         /* DEPRECATED 2025-05-04, NumPy 2.3 */         int ret = PyErr_WarnEx(PyExc_DeprecationWarning,

Not ideal, but at least it makes a start, and we don't need the new_set_dtype method...

Not ideal, but at least it makes a start, and we don't need the new _set_dtype method...

I guess I am not too worried about a_set_dtype if that is the a way make broader progress without larger refactors (including calling it semi-public, but discouraging its use).
However, 2.3 branching is around the corner (<~2 weeks) so especially if you want to push for that and the alternatives are just unwieldy, then omitting subclasses seems like a good way to make a very good start here.

Good point about 2.3 being around the corner. I think following my suggestion is easiest in the sense that it introduces no new API, and we can then think about how to doPyArray_View better. E.g., one could envisage only calling the dtype setter if it is different from the standard one.