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

Olivier Delalleau shish at keba.be
Wed May 23 09:02:40 EDT 2012

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!

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

More information about the NumPy-Discussion mailing list