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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4