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