I'm not convinced they should be added but if they are to be added they can be done fairly simply.
x = (foo oper bar)
Equivalent to:
x = oper(foo, bar)
There's a lot of notes to be made though.
oper is 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.oper can 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 becomes (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 1+(2*3). - [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.
I think that's about it. As I said, I'm not convinced they should be added, but if they are I think this is how it should be done.
2 comments:
This seems too different from how you overload + and -. I think they should just do this:
x·y == x.__middle_dot__(y)
All the Unicode math symbols have official names. And who wouldn't get a kick out of seeing "def __gt__(self, other)" followed by "def __much_greater_than__" and finally "def __very_much_greater_than__"?
If Unicode identifiers are added to Python--and I think they will be, eventually--presumably they still won't allow math symbols. There is a standard.
Anyway, the most important precondition is an easy way to type those symbols.
First a side issue, when did you post this comment? Probably a while ago and I somehow missed it. Unfortunately blogger doesn't think it's important to provide a date (let alone in a ISO 8601 format!)
Yes, my idea would be pretty different. This is necessary to provide arbitrary operator names. Your approach would not provide custom operators at all; instead it would turn various math operators into standard builtin operators and allow them to be overriden.
That said, I think yours is a more reasonable approach. Far simpler all around.
Post a Comment