[Numpy-discussion] copy/deepcopy pull request, Travis build failure

[josef.pktd at gmail.com]

On Thu, Oct 25, 2012 at 11:48 PM, David Warde-Farley
<wardefar at iro.umontreal.ca> wrote:
> 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.
>
> 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

Josef


>
> 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.
>
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion