[Numpy-discussion] copy/deepcopy pull request, Travis build failure
Fri Oct 26 00:04:11 CDT 2012
On Thu, Oct 25, 2012 at 11:48 PM, David Warde-Farley
> On Thu, Oct 25, 2012 at 8:39 PM, <firstname.lastname@example.org> wrote:
>> On Thu, Oct 25, 2012 at 6:58 PM, David Warde-Farley
>> <email@example.com> wrote:
>>> On Thu, Oct 25, 2012 at 6:15 PM, Sebastian Berg
>>> <firstname.lastname@example.org> 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.
> Hi Josef,
> 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.
Fine, I didn't understand that part correctly.
I have no opinion in that case.
(In statsmodels we only use copy the array method and through np.array().)
Thanks for the clarification
> 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
> wasn't possible.
> Frequent users of .copy()/np.copy() who are familiar with *NumPy's*
> API behaviour should be largely unaffected.
> NumPy-Discussion mailing list
More information about the NumPy-Discussion