Looks like there's one docstring that still needs an update:

_________________________ [doctest] basics.copies.rst __________________________
111 
112     >>> import numpy as np
113     >>> x = np.ones((2, 3))
114     >>> y = x.T  # makes the array non-contiguous
115     >>> y
116     array([[1., 1.],
117            [1., 1.],
118            [1., 1.]])
119     >>> z = y.view()
120     >>> z.shape = 6
Differences (unified diff with -expected +actual):
    @@ -1,4 +1,8 @@
     Traceback (most recent call last):
    -   ...
    -AttributeError: Incompatible shape for in-place modification. Use
    -`.reshape()` to make a copy with the desired shape.
    +  File "/home/circleci/.pyenv/versions/3.11.10/lib/python3.11/doctest.py", line 1355, in __run
    +    exec(compile(example.source, filename, "single",
    +  File "<doctest basics.copies.rst[22]>", line 1, in <module>
    +    z.shape = 6
    +    ^^^^^^^
    +DeprecationWarning: Setting the shape on a NumPy array has been deprecated in NumPy 2.4.
    +As an alternative, you can create a new view using np.reshape.

/home/circleci/repo/doc/source/user/basics.copies.rst:120: DocTestFailure

iv) might give issues with subclasses that override setting the shape (is that possible?)

It seems possible, but rather raw:

class arr(np.ndarray):
    @property
    def shape(self):
        return super().shape
    @shape.setter
    def shape(self, val):
        np.ndarray.shape.__set__(self, val)

(I suppose you may be able to walk the __mro__ like super there somehow). But it seems arcane enough that nobody should do it (and why would you?)).

I still think option iv might be nicer, just because the need for this should only arise in the subclass implementation itself and not for end-users. But happy to go with this initially (even this might be quite noisy, of course).

I still think option iv might be nicer, just because the need for this should only arise in the subclass implementation itself and not for end-users. But happy to go with this initially (even this might be quite noisy, of course).

For setting the shape the only complex part is in np.matrixlib which is already deprecated (7 years ago, maybe time to remove it?) so option iv) might indeed be better. I will open a PR with this approach.

Matrix deprecation always waited on SciPy sparse matrix being replaced. That process finally started, but it may not be quite far enough yet to actually do it.
(Plus, maybe we need to escalate the deprecation a bit first considering the impact.)

Ah, sorry, I see you just had to change how the shape is handled there (i.e. that weird offender) and not actually need to get rid of it. To me that seems actually pretty nice and not too complex if it works!