[Numpy-discussion] Should arr.diagonal() return a copy or a view? (1.7 compatibility issue)

Travis Oliphant travis at continuum.io
Wed May 23 13:29:29 EDT 2012

On May 23, 2012, at 8:02 AM, Olivier Delalleau wrote:

> 2012/5/23 Nathaniel Smith <njs at pobox.com>
> On Wed, May 23, 2012 at 6:06 AM, Travis Oliphant <travis at continuum.io> wrote:
> > I just realized that the pull request doesn't do what I thought it did which
> > is just add the flag to warn users who are writing to an array that is a
> > view when it used to be a copy.     It's more cautious and also "copies" the
> > data for 1.7.
> >
> > Is this really a necessary step?   I guess it depends on how many use-cases
> > there are where people are relying on .diagonal() being a copy.   Given that
> > this is such an easy thing for people who encounter the warning to fix their
> > code, it seems overly cautious to *also* make a copy (especially for a rare
> > code-path like this --- although I admit that I don't have any reproducible
> > data to support that assertion that it's a rare code-path).
> >
> > I think we have a mixed record of being cautious (not cautious enough in
> > some changes), but this seems like swinging in the other direction of being
> > overly cautious on a minor point.
> The reason this isn't a "minor point" is that if we just switched it
> then it's possible that existing, working code would start returning
> incorrect answers, and the only indication would be some console spew.
> I think that such changes should be absolutely verboten for a library
> like numpy. I'm already paranoid enough about my own code!
> That's why people up-thread were arguing that we just shouldn't risk
> the change at all, ever.
> I admit to some ulterior motive here: I'd like to see numpy be able to
> continue to evolve, but I am also, like I said, completely paranoid
> about fundamental libraries changing under me. So this is partly my
> attempt to find a way to make a potentially "dangerous" change in a
> responsible way. If we can't learn to do this, then honestly I think
> the only responsible alternative going forward would be to never
> change any existing API except in trivial ways (like removing
> deprecated functions).
> Basically my suggestion is that every time we alter the behaviour of
> existing, working code, there should be (a) a period when that
> existing code produces a warning, and (b) a period when that existing
> code produces an error. For a change like removing a function, this is
> easy. For something like this diagonal change, it's trickier, but
> still doable.
> /agree with Nathaniel. Overly cautious is good!

Then are you suggesting that we need to back out the changes to the casting rules as well, because this will also cause code to stop working.   This is part of my point.   We are not being consistently cautious. 


> -=- Olivier
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120523/0b6e6241/attachment.html>

More information about the NumPy-Discussion mailing list