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. As a rule of thumb, we need to compare the benefit and consequence of changing default behaviour. In this case I see only a marginal speed gain (marginal in the sense that in the global user script, this won't matter, but locally it could be significant) vs silent and hard to find bug. If speed in that case is important, i think it would be much better to write an optimizer version that will take stride and cache line length into account. Even if we hard code the cache line lenght, this will probably bring most of the local speed up, without the inconvenient. If people still want to do this change, I think only a big release like numpy 2.0 make this acceptable but with the warning as Gael told. But I still prefer it not done and if people matter about the speed, they can write optimized code. Fred On Sun, Sep 30, 2012 at 2: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.
That's how I would deal with it. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion