[Python-Dev] Why not support user defined operator overloading ?
steve at pearwood.info
Mon Sep 30 01:31:32 CEST 2013
On Sun, Sep 29, 2013 at 03:35:27PM -0400, Ned Batchelder wrote:
> It isn't just a matter of a more complex parser: where would the parser
> get the information about these new operators? The obvious first answer
> is that they would be defined as part of classes, but that means the
> operator definition is in an imported module some place. The importing
> module couldn't even be parsed until the class was imported. This is a
> completely different compilation and execution model than Python has now.
The obvious place to define the operator's action is a class, but there
is no need to define new syntax at runtime. The parser doesn't need to
know the operator's action until runtime, no different from existing
For avoidance of doubt, I'm not suggesting this as a concrete proposal,
just as a hypothetical. But if somebody wants to take it seriously
and write up a PEP, here are two possibilities to get you started:
* Unicode characters. It's 2013, and anyone still using an editor which
only handles ASCII shouldn't be :-) There are dozens of non-alphanumeric
characters in Unicode that are suitable as operators. Unless I've
missed one, all the existing operators have category 'Sm', 'Sk',
'Po', or 'Pd', so Python might parse any character in those categories
as a potential operator. E.g. all of these are in category Sm:
∈ ∉ ≠ ⊂ ⊃ ⊕ ⊖ ⊗ ⊘
* ASCII digraphs. A more conservative approach would be to define custom
operators as two characters, not one. Say, @X might be parsed as
In either case, having parsed "spam @X eggs" or "spam ⊂ eggs", the
interpreter could do this:
call spam.__op__('X', eggs) # or '⊂'
if that doesn't succeed, call eggs.__rop__('X', spam)
none of which need happen until runtime, same as existing operators.
If you want to also support unary operators (prefix or postfix) then the
parsing rules presumably will become more complicated, but the basic
principle remains: the parser needs a pre-defined "template" to
recognise what looks like an operator, and that can be baked into the
language definition. The actual meaning of the operator can be
determined at run time.
Make no mistake, this is still a big change to Python's semantics. But
it doesn't require Python to redefine syntax on the fly.
More information about the Python-Dev