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