[Numpy-discussion] [help needed] associativity and precedence of '@'

Nathaniel Smith njs at pobox.com
Mon Mar 17 12:13:25 EDT 2014


On Mon, Mar 17, 2014 at 4:09 PM, Alexander Belopolsky <ndarray at mac.com> wrote:
>
> On Mon, Mar 17, 2014 at 11:48 AM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> > One more question that I think should be answered by the PEP and may
>> > influence the associativity decision is what happens if in an A @ B @ C
>> > expression, each operand has its own type that defines __matmul__ and
>> > __rmatmul__?  For example, A can be an ndarray, B a sympy expression and
>> > C a
>> > pyoperator.
>>
>> The general rule in Python is that in a binary operation A # B, then
>> first we try A.__special__, and if that doesn't exist or it returns
>> NotImplemented, then we try B.__rspecial__. (The exception is that if
>> B.__class__ is a proper subclass of A.__class__, then we do it in the
>> reverse order.)
>
> This is the simple case.  My question was: "what happens if in an A @ B @ C
> expression, each operand has its own type that defines __matmul__ and
> __rmatmul__?"

The point of associativity is that the complex case A @ B @ C gets
turned into either A @ (B @ C) or else (A @ B) @ C, and then you're
back in the simple case.

> Are we going to recommend that other projects adopt numpy's
> __array_priority__?
>
> In mixed-type expressions, do you expect A @ B @ C to have type of A, B, or
> C?
>
> Does __matmul__ first then __rmatmul__ rule makes sense if @ becomes
> right-associative or should the order be reversed?

** is right-associative and uses the left-then-right rule, so it seems
fine to me.

In general the left-then-right rule has no particular logic behind it,
it's just chosen so as to have *some* rule. In practice all
well-behaved classes have to make sure that they implement __special__
methods in such a way that all the different variations work, no
matter which class ends up actually handling the operation.

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org



More information about the NumPy-Discussion mailing list