Why not support user defined operator overloading ?
Hello: As far as I know, there is not a language support user defined operator overloading. Python3 can overloading belowed operators. - negated + unchanged - minus + add * multiplication / division // true division % remainder ** power (Do I miss something ?) If we can overloading these operators, why we can't overloading other operators? (like .* often used in matrix, U in set operation) Regards! Peipei
On 2013-09-29, at 14:51 , 张佩佩 wrote:
Hello: As far as I know, there is not a language support user defined operator overloading. Python3 can overloading belowed operators. - negated + unchanged
- minus + add * multiplication / division // true division % remainder ** power (Do I miss something ?)
~ invert (unary) () call . get attribute [] get item << left shift
right shift
& binary and ^ xor | binary or
And the inplace versions of most of these can be implemented separately, which can probably be counted as supplementary operators.
If we can overloading these operators, why we can't overloading other operators? (like .* often used in matrix, U in set operation)
This is more of a python-ideas subject. And one of the reasons likely is that it would require significantly reworking the grammar to handle a kind of user-defined opname (similar to name, but for operator tokens), with user-defined priority and associativity, and the ability to import operators (or define how and when operators become available compared to their definition) That's a huge amount of complexity with little to gain.
On 9/29/13 11:06 AM, Xavier Morel wrote:
This is more of a python-ideas subject.
And one of the reasons likely is that it would require significantly reworking the grammar to handle a kind of user-defined opname (similar to name, but for operator tokens), with user-defined priority and associativity, and the ability to import operators (or define how and when operators become available compared to their definition)
That's a huge amount of complexity with little to gain.
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. Now you can compile a Python module without any access to the modules it will eventually import. Importing is a run-time operation. If you want user-defined classes to be able to define new syntax, then importing has to happen at compile time. That's a completely different language. --Ned.
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
Steven D'Aprano wrote:
there is no need to define new syntax at runtime. The parser doesn't need to know the operator's action until runtime
It does need to know the operator's precedence and associativity, though, which means either declaring it somewhere, or having some kind of fixed rule. -- Greg
On Sun, Sep 29, 2013 at 08:51:37PM +0800, 张佩佩 wrote:
Hello: As far as I know, there is not a language support user defined operator overloading. Python3 can overloading belowed operators. [...] (Do I miss something ?)
Yes, many. http://docs.python.org/3/reference/datamodel.html#special-method-names http://docs.python.org/3/reference/datamodel.html#emulating-numeric-types
If we can overloading these operators, why we can't overloading other operators? (like .* often used in matrix, U in set operation)
http://www.python.org/dev/peps/pep-0211/ http://www.python.org/dev/peps/pep-0225/ There is a good argument for being able to overload element-wise and object-wise operators. However, I don't think it is good to be able to create arbitrary new operators, e.g. a X b for an X operator. We already have syntax for arbitrary functions, and they aren't limited to binary operators: X(a, b, c, d, ...) works better than a X b for most uses. -- Steven
张佩佩 writes:
If we can overloading these operators, why we can't overloading other operators? (like .* often used in matrix, U in set operation)
AIUI, it's considered unpythonic. Operators are considered to be part of the *syntax* of Python, unlike Haskell, where infix syntax can be used for any function, and operators can be called via function syntax. (The latter is true in Python as well, but it is very bad form to do that, sufficiently verbose that it is hardly tempting, and it can easily fail because Python operators are polymorphic, but the implementations via class methods are not.) I'm sure it also simplifies parsing.
participants (6)
-
Greg Ewing -
Ned Batchelder -
Stephen J. Turnbull -
Steven D'Aprano -
Xavier Morel -
张佩佩