[Python-Dev] Why not support user defined operator overloading ? (original) (raw)
Steven D'Aprano steve at pearwood.info
Mon Sep 30 01:31:32 CEST 2013
- Previous message: [Python-Dev] Why not support user defined operator overloading ?
- Next message: [Python-Dev] Why not support user defined operator overloading ?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Why not support user defined operator overloading ?
- Next message: [Python-Dev] Why not support user defined operator overloading ?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]