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/