On Mar 20, 2014, at 3:02 PM, Nathaniel Smith wrote:
> - And anyway, my impression is that python-dev will give these other
> possible uses ~zero weight anyway -- if they thought random DSL
> operators were important for their own sake, they would have added @
> long ago :-).
Unlike what you all seem to think, I *don't* want '@' as a DSL.
As I said, I'm a same-left person. There's very little additional
power in same-left for a DSL, over the other 4 available operators.
I think that weakness is a good thing.
I'm saying that it will be (ab)used in a DSL. Given no strong bias
one way or another, I prefer to minimize any temptations or weird
effects that a new precedence level might cause. Hence why I prefer
that it act either the same as "*" or as "**", and to keep it from
being more widely used, I more strongly prefer it the same as "*".
You say "we've been asked to report back on what design of @ will
be best for the numeric community, since that's where we have special
expertise that python-dev lacks." I don't really think that goal
means you can avoid considering all non-numeric consequences.
Nor do I think I'm making any weighty arguments here. My observation
though is that the signal so far is low enough that second-order
effects are likely to have some influence in the final decision,
either here or with python-dev.
On Mar 20, 2014, at 2:31 PM, Robert Kern wrote:
> Really? I mean, |, ^, and & *each* get their own precedence level. I'm
> not really sure that there is an aversion to adding precedence levels.
> In fact, it almost seems like the opposite: everything gets its own
> level unless if they obviously go together.
No new expression precedence level has been added since ** in
January 1996, at least, not that I can identify. Those boolean ones
you mentioned were added in October 1991 and follows the C operator
precedence. Given the number of other languages do the same, and
Python's goals, this makes sense. The ** was a secondary influence
by Fortran.
The closest Python came since 1996 is support for the if/else
expression, but that has the same precedence as lambda. Eg,
compare 3.4:
test: or_test ['if' or_test 'else' test] | lambdef
to 1.5.2:
test: and_test ('or' and_test)* | lambdef
(The documentation says they are at different levels, but
they actually are at the same. Consider:
lambda: 1 if print('hi') else print('bye')
This is not the same as
(lambda: 1) if print('hi') else print('bye')
.)
If you came from a Pascal background then you would expect
'+' '-' 'or' and 'xor' to have the same precedence, since
the adding operators obviously go together.
While, oddly enough, C's == is not at the same level as <=,
which suggests that the Dennis Ritchie at one time didn't
think it was obvious that those two go together. (Then again,
he also started off with a =- 1 instead of a -= 1.)
The arguments against a complex precedence table are
well-trod ground. See:
http://stackoverflow.com/questions/6320424/
http://c2.com/cgi/wiki?OperatorPrecedenceConsideredHarmful
Larry Wall's summary about operator precedence in
http://perl6.org/archive/doc/design/apo/A03.html is apropos
to the general topic of deciding upon operator precedence.
Cheers,
Andrew
da...@dalkescientific.com
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
