<br><br><div class="gmail_quote">2012/5/23 Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div><div class="h5"><div>On May 23, 2012, at 8:02 AM, Olivier Delalleau wrote:</div><br><blockquote type="cite"><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>On Wed, May 23, 2012 at 6:06 AM, Travis Oliphant <<a href="mailto:travis@continuum.io" target="_blank">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></div></div></blockquote><div><br></div></div></div><div>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. </div>
<div><br></div><div>-Travis</div></div></div></blockquote><div><br>Well, about casting rules... they've already been broken multiple times in previous releases (at least between 1.5 and 1.6, although I think I remember seeing some inconsistent behavior with older versions as well, but I'm less sure). So in some sense it's already too late, and it shouldn't hurt much more to break them again :P<br>
But yes, breaking them in the first place was bad. I spent a lot of time trying to figure out what was going on.<br><br>Although I just said I don't think it's a big deal to break them again, if it's easy enough to add a warning on operations whose casting behavior changed, with an option to disable this warning (would probably need to be a global numpy setting -- is there a better way?), I would actually like it even better.<br>
<br>-=- Olivier<br></div></div>