<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 19, 2015 at 8:28 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Oct 19, 2015 at 7:23 PM, Jonathan Helmus <span dir="ltr"><<a href="mailto:jjhelmus@gmail.com" target="_blank">jjhelmus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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?<br>
<br>
For a concrete example of this behavior and possible changes, what type should copy_x be in the following snippet:<br>
<br>
import numpy as np<br>
x = np.ma.array([1,2,3])<br>
copy_x = np.copy(x)<br></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>Chuck <br></div><br></div></div></div>