On Mon, Oct 1, 2012 at 8:35 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux <gael.varoquaux@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.