[Numpy-discussion] copy/deepcopy pull request, Travis build failure
Thu Oct 25 19:39:20 CDT 2012
On Thu, Oct 25, 2012 at 6:58 PM, David Warde-Farley
> 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.
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.
(I'm using numpy 1.5 help file, so maybe I'm outdated.)
> NumPy-Discussion mailing list
More information about the NumPy-Discussion