[Python-Dev] Why not support user defined operator overloading ?

[Steven D'Aprano]

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 
operators.

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 
operator X.

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)
raise OperatorError

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.


-- 
Steven