On Wed, 2012-05-23 at 17:31 -0500, Nathaniel Smith wrote:
> On Wed, May 23, 2012 at 10:53 PM, Travis Oliphant <travis(a)continuum.io> wrote:
> > To be clear, I'm not opposed to the change, and it looks like we should go forward.
> > In my mind it's not about developers vs. users as satisfying users is the whole point. The purpose of NumPy is not to make its developers happy :-). But, users also want there to *be* developers on NumPy so developer happiness is not irrelevant.
> > In this case, though, there are consequences for users because of the double copy if a user wants to make their code future proof. We are always trading off predicted user-experiences. I hope that we all don't have the same perspective on every issue or more than likely their aren't enough voices being heard from real users.
> I'm not really worried about users who have a problem with the
> double-copy. It's a totally legitimate concern, but anyone who has
> that concern has already understood the issues well enough to be able
> to take care of themselves, and decided that it's worth the effort to
> special-case this. They can check whether the returned array has .base
> set to tell whether it's an array or a view, use a temporary hack to
> check for the secret warning flag in arr.flags.num, check the numpy
> version, all sorts of things to get them through the one version where
> this matters. The suggestion in the docs to make a copy is not exactly
> binding :-).
> -- Nathaniel
As a "real user", if I care about whether an array arr2 is a copy or a
view, I usually either check arr2.flags.owndata or append copy() to the
statement that created arr2, e.g., arr2 = arr.diagonal().copy().
Numpy rules on views vs. copies sometimes require a bit of thought, and
so I'll frequently just check the flags or make a copy instead of
thinking. (More foolproof :).)