On Wed, Jun 26, 2019 at 11:24 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
Hi Ralf,
I realize you feel strongly that this whole thread is rehashing history,
The .H part was. But Cameron volunteered to work on a solution that satisfies all concerns. but I think it is worth pointing out that many seem to consider that the
criterion for allowing backward incompatible changes, i.e., that "existing code is buggy or is consistently confusing many users", is actually fulfilled here.
Indeed, this appears true to such an extent that even those among the steering council do not agree: while the topic of this thread was about introducing *new* properties (because in the relevant issue I had suggested to Steward it was not possible to change .T), it was Eric who brought up the question whether we shouldn't just change `.T` after all.
Yes, and then he came up with a better suggestion in https://github.com/numpy/numpy/issues/13835. If a comment starts with "this may be contentious" and then real-world correct code like in scikit-image shows up, it's better not to dig it back up after 60 emails to make your point..... And in the relevant issue, Sebastian noted that "I am not quite convinced
that we cannot change .T (at least in the sense of deprecation)
deprecation I interpret as "to raise an error after" myself", with Chuck chiming in that "I don't recall being in opposition,
and I also think the current transpose is not what we want."
That makes three of your fellow steering council members who are not sure, despite all the previous discussions (of which Chuck surely has seen most - sorry, Chuck!).
It seems to me the only sure way in which we can avoid future discussions is to actually address the underlying problem. E.g., is the cost of deprecating & changing .T truly that much more than even having this discussion?
Yes it is. Seriously, every time someone proposes something like this, eventually a better solution is found. Raising for .T on >2-D is a possibility, in case the problem is really *that* bad (which doesn't seem to be the case - but if so, please propose that instead). Changing the meaning of .T to give changed numerical results is not acceptable (not just my opinion, also Matthew, Alan, and Stephan said no). If you've been on this list for a few years, you really should understand that by now. I'll quote Matthew again, who said it best: "Under no circumstances should we make changes that mean that correct old code will give different results with new Numpy. On the other hand, it's OK (with a suitable period of deprecation) for correct old code to raise an informative error with new Numpy." Cheers, Ralf