On Mon, Mar 17, 2014 at 4:09 PM, Alexander Belopolsky <ndarray@mac.com> wrote:
On Mon, Mar 17, 2014 at 11:48 AM, Nathaniel Smith <njs@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