I don’t find the article clear on how it fixes things, but I guess that, now

  a op1 b op2 c

is an error if op1 is unequal to op2 and they have the same precedence. Do I see that right?

Also, it seems each operator will have to have a associativity to handle a future operator for exponentiation or (also potential future) custom operators.

Finally, the “What you need to know” section doesn’t mention orelse. Where does that fit in?

▲ dan-robertson 3 hours ago | parent | next [-]

The point is that there is no longer a global ‘precedence number’ where the operator with the higher precedence binds tighter. Instead, it is only valid to write your example for some combinations of op1 and op2; other combinations will require explicit parentheses.

Presumably orelse is not in the table because it requires parentheses for any other operator.

	▲	Someone 6 minutes ago \| parent [-]
		I would hope they implemented it with precedence numbers, as any other way is likely to be harder to write and lead to inconsistencies. It’s harder to write because users will want to use expressions with more than one operator such as `b * b - 4 * a * c a * b + c * d > e * f and g < h`

▲ 2 hours ago | parent | prev [-]

[deleted]