[Numpy-discussion] copy/deepcopy pull request, Travis build failure
wardefar at iro.umontreal.ca
Thu Oct 25 23:48:28 EDT 2012
On Thu, Oct 25, 2012 at 8:39 PM, <josef.pktd at gmail.com> wrote:
> On Thu, Oct 25, 2012 at 6:58 PM, David Warde-Farley
> <wardefar at iro.umontreal.ca> wrote:
>> On Thu, Oct 25, 2012 at 6:15 PM, Sebastian Berg
>> <sebastian at sipsolutions.net> wrote:
>>> On Thu, 2012-10-25 at 17:48 -0400, David Warde-Farley wrote:
>>> Don't worry about that failure on Travis... It happens randomly on at
>>> the moment and its unrelated to anything you are doing.
>> Ah, okay. I figured it was something like that.
>>> I am not sure though you can change behavior like that since you also
>>> change the default behavior of the `.copy()` method and someone might
>>> rely on that?
>> Oops, you're right. I assumed I was changing __copy__ only. Pull
>> request updated.
>> Given that behaviour is documented it really ought to be tested. I'll add one.
>>> Maybe making it specific to the copy model would make it
>>> unlikely that anyone relies on the default, it would seem sensible that
>>> copy.copy(array) does basically the same as np.copy(array) and not as
>>> the method .copy, though ideally maybe the differences could be removed
>>> in the long run I guess.
>> Agreed, but for now the .copy() method's default shouldn't change. I
>> think the scikit-learn usecase I described is a good reason why the
>> copy protocol methods should maintain data ordering, though.
> I think this might be something that could wait for a big numpy version change.
> At least I always assumed that a new array created by copying is the default
> numpy C order (unless otherwise requested).
> I never rely on it except sometimes when I think about speed of operation in
> fortran versus c order.
> np.copy says:
> This is equivalent to
>>>> np.array(a, copy=True)
> numpy.ma.copy has the order keyword with "c" as default
> changing the default from "C" to "A" doesn't look like a minor API change.
Just to be clear: this pull request (
https://github.com/numpy/numpy/pull/2699 ) affects only the behaviour
when arrays are copied with the standard library "copy" module. The
use of the .copy() method of ndarrays, or the numpy.copy library
function, remains the same, with all defaults intact. An oversight on
my part had briefly changed it, but Sebastian pointed this out and
I've updated the PR.
The main application is, as I said, with objects that have ndarray
members and interface with external code that relies on Fortran
ordering of those ndarray members (of which there are several in
scikit-learn, as one example). An object once deepcopy'd should
ideally "just work" in any situation where the original worked, but
with the current implementation of the copy protocol methods this
Frequent users of .copy()/np.copy() who are familiar with *NumPy's*
API behaviour should be largely unaffected.
More information about the NumPy-Discussion