x = (foo oper bar)Equivalent to:
x = oper(foo, bar)There's a lot of notes to be made though.
operis looked up in the local (and global) namespaces, not as a method of foo or bar. If you want it to be a method you need to make the local/global function do all the lookups itself.
opercan only be a single name. It cannot be an expression. The reason is that
((foo)(bar)(baz))is currently legal, meaning
(foo(bar))(baz). A limited subset of expressions could be permitted, but I feel it is better to educate users on a "no tolerance" policy.
- Custom operators only become really useful when Unicode variable names are permitted.
- There's never a question of precedence with this syntax (unlike builtin operators).
- Most builtin operators could be altered to use this syntax, but it would make them a bit more verbose.
(1 + (2 * 3)). However, this bloat can be countered by making parsing aware of word boundaries and by making the parenthesis optional under most conditions. Then you return to
- [Edit] Perhaps the biggest drawback is requiring the user to explicitly import all operators that may be used, ie
from math import ×, ≺, ≻, ≼, ≽, ⊀, ⊁, ∈, ∉, ∋, ∌, ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋, ∩, ∪, ∖, etc. An alternative would be defining a protocol that does use a method of one of the arguments. Unfortunately that significantly increases the complexity of my proposal, so I'll leave it as an exercise for the reader.