A simple suggestion: what about defining the special methods as __at__, __rat__, __iat__ (@) and __atat__, __ratat__, __iatat__ (@@)? This make the operator more "neutral" -- it make it sound less "wrong" to overload it for something else that matrix multiplication (which is certainly an important topic, but even though I use numpy quite a lot, I don't actually use it at all for linear algebra (in fact I use elementwise multiplications much more often) -- so counting imports of numpy is a somewhat biaised metric for counting users of matrix multiplication). Antony 2014-03-14 10:53 GMT-07:00 Guido van Rossum <guido@python.org>:
I have now read the PEP, and I think it's good. I think it's a waste of time to keep bikeshedding on the choice of operator -- @ is the best compromise. I do have a few specific notes:
- Right associativity is not unheard of in Python. E.g. **. If you think that for other reasons @ should be right associative, don't let Python's tradition stop you. But then you need to decide which of * and @ binds more tightly -- e.g. does a*b@c mean a*(b@c) or (a*b)@c? And if you choose the latter, it follows that a@b*c means a@(b*c) -- is that okay? (And similar examples exist for the other choice.)
- Did you consider a duck-typing (is that the word?) attribute? E.g. a*b is elementwise multiplication; a.M*b must be used for matrix multiplication. (Your use of .T as "transpose" made me think of this.) Of course the question is, can you get those packages that currently use * for matrix multiply to comply? (I don't consider this a serious counter-proposal. But you list a bunch of rejected alternatives; this could be in that list.
- Is @@ really necessary? It seems you are adding it mostly because it's cute and because of the parallel with **, not because it is actually important enough to add new syntax. And then later you use it as an argument for @, which seems a bit circular. Also, if we were to make @ right-associative, the parallel with ** is already imperfect.
- For better counts of usages, perhaps Sourcegraph.com might help? It is a source code query engine that has a Python parser and (limited) type inference built in (also separately available as pysonar on github IIRC). To be clear, I don't need more numbers to be convinced.
Once we've decided on associativity and @@, I'm ready to accept.
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/