If I remember correctly, [numpy.future imports are] actually possible but hacky. So it would probably be nicer to not go there.
There was some discussion of this at https://stackoverflow.com/q/29905278/102441. I agree with the conclusion we should not go there - in particular, note that every builtin __future__ feature has been an interpreter-level change, not an object-level change. from __future__ import division changes the meaning of / not of int.__div__. Framing the numpy change this way would mean rewriting Attribute(obj, attr, Load) ast nodes to Call(np._attr_override, obj, attr), which is obvious not interoperable with any other module wanting to do the same thing. This opens other unpleasant cans of worms about “builtin” modules that perform attribute access: Should getattr(arr, 'T') change behavior based on the module that calls it? Should operator.itemgetter('T') change behavior ? So I do not think we want to go down that road. On Sun, 23 Jun 2019 at 14:28, Sebastian Berg <sebast...@sipsolutions.net> wrote: > > On Sun, 2019-06-23 at 17:12 -0400, Marten van Kerkwijk wrote: > > Hi All, > > > > I'd love to have `.T` mean the right thing, and am happy that people > > are suggesting it after I told Steward this was likely off-limits > > (which, in fairness, did seem to be the conclusion when we visited > > this before...). But is there something we can do to make it possible > > to use it already but ensure that code on previous numpy versions > > breaks? (Or works, but that seems impossible...) > > > > For instance, in python2, one had `from __future__ import division > > (etc.); could we have, e.g., a `from numpy.__future__ import > > matrix_transpose`, which, when imported, implied that `.T` just did > > the right thing without any warning? (Obviously, since that > > __future__.matrix_transpose wouldn't exist on older versions of > > numpy, it would correctly break the code when used with those.) > > > > If I remember correctly, this is actually possible but hacky. So it > would probably be nicer to not go there. But yes, you are right, that > would mean that we practically limit `.T` to 2-D arrays for at least 2 > years. > > > Also, a bit more towards the original request in the PR of a > > hermitian transpose, if we're trying to go for `.T` eventually having > > the obvious meaning, should we directly move towards also having `.H` > > as a short-cut for `.T.conj()`? We could even expose that only with > > the above future import - otherwise, the risk of abuse of `.T` would > > only grow... > > This opens the general question of how many and which attributes we > actually want on ndarray. My first gut reaction is that I am -0 on it, > but OTOH, for some math it is very nice and not a huge amount of > clutter... > > > > > > Finally, on the meaning of `.T` for 1-D arrays, the sensible choices > > would seem to (1) error; or (2) change shape to `(n, 1)`. Since while > > writing this sentence I changed my preference twice, I guess I should > > go for erroring (I think we need a separate solution for easily > > making stacks of row/column vectors). > > Probably an error is good, which is nice, because we can just tag on a > warning and not worry about it for a while ;). > > > > > All the best, > > > > Marten > > > > On Sun, Jun 23, 2019 at 4:37 PM Sebastian Berg < > > sebast...@sipsolutions.net> wrote: > > > On Sun, 2019-06-23 at 19:51 +0000, Hameer Abbasi wrote: > > > > +1 for this. I have often seen (and sometimes written) code that > > > does > > > > this automatically, and it is a common mistake. > > > > > > Yeah, likely worth a short. I doubt many uses for the n-dimensional > > > axis transpose, so maybe a futurewarning approach can work. If not, > > > I > > > suppose the solution is the deprecation for ndim != 2. > > > > > > Another point about the `.T` is the 1-dimensional case, which > > > commonly > > > causes confusion. If we do something here, should think about that > > > as > > > well. > > > > > > - Sebastian > > > > > > > > > > > > > > However, we will need some way to filter for intent, as the > > > people > > > > who write this code are the ones who didn’t read docs on it at > > > the > > > > time, and so there might be a fair amount of noise even if it > > > fixes > > > > their code. > > > > > > > > I also agree that a transpose of an array with ndim > 2 doesn’t > > > make > > > > sense without specifying the order, at least for the applications > > > I > > > > have seen so far. > > > > > > > > Get Outlook for iOS > > > > > > > > From: NumPy-Discussion < > > > > numpy-discussion-bounces+einstein.edison=gmail....@python.org> on > > > > behalf of Eric Wieser <wieser.eric+nu...@gmail.com> > > > > Sent: Sunday, June 23, 2019 9:24 PM > > > > To: Discussion of Numerical Python > > > > Subject: Re: [Numpy-discussion] Syntax Improvement for Array > > > > Transpose > > > > > > > > This might be contentious, but I wonder if, with a long enough > > > > deprecation cycle, we can change the meaning of .T. That would > > > look > > > > like: > > > > > > > > * Emit a future warning on `more_than_2d.T` with a message like > > > "in > > > > future .T will transpose just the last two dimensions, not all > > > > dimensions. Use are.transpose() if transposing all {n} dimensions > > > is > > > > deliberate" > > > > * Wait 5 releases or so, see how many matches Google / GitHub has > > > for > > > > this warning. > > > > * If the impact is minimal, change .T > > > > * If the impact is large, change to a deprecation warning > > > > > > > > An argument for this approach: a good amount of code I've seen in > > > the > > > > wild already assumes T is a 2d transpose, and as a result does > > > not > > > > work correctly when called with stacks of arrays. Changing T > > > might > > > > fix this broken code automatically. > > > > > > > > If the change would be too intrusive, then keeping the > > > deprecation > > > > warning at least prevents new users deliberately using .T for >2d > > > > transposes, which is possibly valuable for readers. > > > > > > > > Eric > > > > > > > > > > > > On Sun, Jun 23, 2019, 12:05 Stewart Clelland < > > > > stewartclell...@gmail.com> wrote: > > > > > Hi All, > > > > > > > > > > Based on discussion with Marten on github, I have a couple of > > > > > suggestions on syntax improvements on array transpose > > > operations. > > > > > > > > > > First, introducing a shorthand for the Hermitian Transpose > > > > > operator. I thought "A.HT" might be a viable candidate. > > > > > > > > > > Second, the adding an array method that operates like a normal > > > > > transpose. To my understanding, > > > > > "A.tranpose()" currently inverts the usual order of all > > > dimensions. > > > > > This may be useful in some applications involving tensors, but > > > is > > > > > not what I would usually assume a transpose on a multi- > > > dimensional > > > > > array would entail. I suggest a syntax of "A.MT" to indicate a > > > > > transpose of the last two dimensions by default, maybe with > > > > > optional arguments (i,j) to indicate which two dimensions to > > > > > transpose. > > > > > > > > > > I'm new to this mailing list format, hopefully I'm doing this > > > right > > > > > :) > > > > > > > > > > Thanks, > > > > > Stew > > > > > _______________________________________________ > > > > > NumPy-Discussion mailing list > > > > > NumPy-Discussion@python.org > > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > > > > _______________________________________________ > > > > NumPy-Discussion mailing list > > > > NumPy-Discussion@python.org > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
