On Mon, Oct 1, 2012 at 8:35 AM, Nathaniel Smith <n...@pobox.com> wrote: > On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux > <gael.varoqu...@normalesup.org> wrote: >> On Sun, Sep 30, 2012 at 07:17:42PM +0100, Nathaniel Smith wrote: >>> Is there anything better to do than simply revert np.copy() to its >>> traditional behaviour and accept that np.copy(a) and a.copy() will >>> continue to have different semantics indefinitely? >> >> Have np.copy take an 'order=None', which would translate to 'K'. Detect >> 'None' as a sentinel that order as not been specified. If the order is >> not specified, raise a FutureWarning that np.copy will change semantics >> in 2 releases. In two releases, do the change. > > I'm actually suggesting that arr.copy() should change, rather than > np.copy() (the opposite of the change currently in master), but that > aside: the problem with this approach is that the vast majority of > calls to these functions don't care at all about this order thing, so > spewing warnings all over the place is pretty useless at helping > people actually detect and fix their code. Compare to the > np.diagonal() change in 1.7, where we don't issue a warning when > np.diagonal() is called, but wait until people write to the array.
I'm +1 on changing a.copy() to be more consistent with np.copy()/np.array(copy=True), but would push it to 2.0 (or whatever release API changes are next expected). I would not worry about a FutureWarning, for this reason. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion