[Numpy-discussion] Behavior of numpy.copy with sub-classes

[Benjamin Root]

In many other parts of numpy, calling the numpy function that had an
equivalent array method would result in the method being called. I would
certainly be surprised if the copy() method behaved differently from the
np.copy() function.

Now it is time for me to do some grepping of my code-bases...

On Mon, Oct 19, 2015 at 10:40 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> On Mon, Oct 19, 2015 at 8:28 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Oct 19, 2015 at 7:23 PM, Jonathan Helmus <jjhelmus at gmail.com>
>> wrote:
>>
>>> In GitHub issue #3474, a number of us have started a conversation on how
>>> NumPy's copy function should behave when passed an instance which is a
>>> sub-class of the array class.  Specifically, the issue began by noting that
>>> when a MaskedArray is passed to np.copy, the sub-class is not passed
>>> through but rather a ndarray is returned.
>>>
>>> I suggested adding a "subok" parameter which controls how sub-classes
>>> are handled and others suggested having the function call a copy method on
>>> duck arrays.  The "subok" parameter is implemented in PR #6509 as an
>>> example. Both of these options would change the API of numpy.copy and
>>> possibly break backwards compatibility.  Do others have an opinion of how
>>> np.copy should handle sub-classes?
>>>
>>> For a concrete example of this behavior and possible changes, what type
>>> should copy_x be in the following snippet:
>>>
>>> import numpy as np
>>> x = np.ma.array([1,2,3])
>>> copy_x = np.copy(x)
>>>
>>
>> FWIW, it looks like np.copy() is never used in our code to work with the
>> ndarray subclass we maintain in yt. Instead we use the copy() method much
>> more often, and that returns the appropriate type. I guess it makes sense
>> to have the type of the return value of np.copy() agree with the type of
>> the copy() member function.
>>
>> That said, breaking backwards compatibility here before numpy 2.0 might
>> very well break real code. It might be worth it search e.g. github for all
>> instances of np.copy() to see if they're dealing with subclasses.
>>
>
> The problem with github searches is that there are a ton of numpy forks.
> ISTR once finding a method to avoid them, but can't remember what is was.
> If anyone knows how to do that, I'd appreciate learning.
>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151020/20a3a73d/attachment.html>