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
da...@dalkescientific.com
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
