On Thu, Oct 25, 2012 at 11:48 PM, David Warde-Farley <warde...@iro.umontreal.ca> wrote: > On Thu, Oct 25, 2012 at 8:39 PM, <josef.p...@gmail.com> wrote: >> On Thu, Oct 25, 2012 at 6:58 PM, David Warde-Farley >> <warde...@iro.umontreal.ca> wrote: >>> On Thu, Oct 25, 2012 at 6:15 PM, Sebastian Berg >>> <sebast...@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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
