On Mon, Oct 1, 2012 at 8:35 AM, Nathaniel Smith wrote:
> On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux
> 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
On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux
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 semant
As always, I think it is better to don't change the default behaviour.
There is many people that don't update frequently and 2 releases is
not enough. This will lead to many hard to find bug. This will also
give the impression what we can't rely on numpy default behaviour and
numpy is not stable.
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 w
There are three basic Python APIs to copy an array in numpy:
a.copy(): has always returned a C-contiguous array by default. has
always taken an order= argument, which defaults to "C".
np.array(a, copy=True): by default, produces an array with whatever
memory ordering that 'a' had. Can also spe
