[Python-Dev] ANN: PEP 335: Overloadable Boolean Operators (original) (raw)
Kevin Jacobs jacobs at theopalgroup.com
Tue Sep 14 14:04:45 CEST 2004
- Previous message: [Python-Dev] ANN: PEP 335: Overloadable Boolean Operators
- Next message: [Python-Dev] ANN: PEP 335: Overloadable Boolean Operators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Phillip J. Eby wrote:
My main concern about the PEP is that it adds overhead to all logical operations, but the feature will only benefit code that hasn't yet been written.
Actually, there are several packages that implement ugly workarounds for exactly this issue. So, in a sense, there is a significant amount of code that exists that will benefit from this feature. Some that come to mind are my own SQL ADT library, SQLObject, and several parser tools.
For these reasons, I'd feel more comfortable with either a literal syntax (to address algebra, SQL, etc.) or some type of special infix notation to allow new operators to be defined in Python, so that it isn't necessary to use prefix or method notation to perform operations like these. Neither of these solutions burdens applications that don't need the feature(s).
Both of your alternatives are being used in some form and neither is really satisfactory. Literal representations require complex parsers, when the Python parser is really what is desired. The infix notation idea is interesting, however the operators desired are usually 'logical and' and 'logical or', which are clearly spelled 'and' and 'or' in Python. I see it as a semantic limitation that Python does not allow overriding these operators. Adding extra indirection (i.e., extra byte codes) will affect performance, but my view is that correctness and completeness are more important than performance.
-Kevin
- Previous message: [Python-Dev] ANN: PEP 335: Overloadable Boolean Operators
- Next message: [Python-Dev] ANN: PEP 335: Overloadable Boolean Operators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]