On 15 Mar 2014 04:42, "Antony Lee" <antony.lee@berkeley.edu> wrote:
>
> 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).

The method name for "*" is "__mul__" rather than "__star__", and so on for the other types. Naming the magic methods for their intended semantics rather than their syntax is an established pattern.

A few other miscellaneous comments:

- nice work on the PEP Nathaniel!
- as with others, "@" as the operator doesn't thrill me, but I also think it crosses the threshold of "good enough given the constraints"
- the PEP should probably recommend adding an "operator.matmul" function, a "PyObject_MatrixMultiply" C API and consider whether or not the new special method should be given a C level type slot.

Cheers,
Nick.

>
> 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/
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/