[Numpy-discussion] Memory order of array copies

[Thouis (Ray) Jones]

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