[Numpy-discussion] Syntax Improvement for Array Transpose

[Ralf Gommers]

On Wed, Jun 26, 2019 at 11:24 PM Marten van Kerkwijk <
m.h.vankerkwijk at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190626/5c46cf61/attachment.html>