On Mar 20, 2014, at 10:07 AM, Robert Kern wrote:
I think the operator-overload-as-DSL use cases actually argue somewhat for right-associativity. ... Right-associativity adds some diversity into the ecosystem and opens up some design space.
You say that like it's a good thing. My argument is that anything which adds another line to Python's precedence table is a bad idea. Unless there's a really good reason for it. The two examples were the best I could come up with, and I don't think they are that persuasive. Looking at the table, the only places for it are on the *, /, //, % line or on the ** line. Since ** is right-associative, then the diversity argument combined with the "no new line" argument means @ should be on the same line, and with the same precedence, as ** In DSL space, that means @ could be used as the inverse of ** by those who want to discard any ties to its use in numerics. Considering it now, I agree this would indeed open up some design space. I don't see anything disastrously wrong for that in matrix/vector use, though my intuition on this is very limited. I believe this gives results like the "strong right" option, no? As an observation, if this is done, and if you want operators to look symmetrical at the syntax level, and if a matrix exponentiation operator isn't critical, then perhaps use '@@' for matrix multiplication, and leave '@' for decorators? It would be a small reminder that '@@' has higher precedence than '*', and may help reduce the momentary confusion upon seeing something like @a@b @c def f(): pass Of course, "f(*x, **y)" are perfectly good unary-looking uses of '*' and '**' and don't cause confusion with the binary forms, so this is all that strong of an objection. Cheers, Andrew dalke@dalkescientific.com