[Python-Dev] ANN: PEP 335: Overloadable Boolean Operators (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue Sep 14 17:43:05 CEST 2004

At 08:04 AM 9/14/04 -0400, Kevin Jacobs wrote:

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.

Maybe you missed the earlier part of the thread, where I was suggesting that a Python "code literal" or "AST literal" syntax would be helpful. For example, if backquotes didn't already have a use, one might say something like:

 db.query(`x.y==z and foo*bar<27`)

To pass an AST object to the db.query() method. The advantage would be that the AST would be parsed and syntax checked at compile time, rather than runtime.

After several experiments with using &, |, and ~ for query expressions, I've pretty much quit and gone to using string literals, since AST literals don't exist. But if AST literals did exist, I'd certainly use them in preference to strings.

But, even if PEP 335 were implemented, creating a query system using Python expressions would still be kludgy, because you still need "seed variables" in the current scope to write a query expression. In my example above, I didn't need to bind 'x' or 'y' or 'z' or 'foo' or 'bar', because the db.query() method is going to interpret those in some context. If I were using a PEP 335-based query system, I'd have to initialize those variables to special querying objects first.

From my POV, the use of &, |, and ~ were very minor issues. Being able to use 'and', 'or', and 'not' would provided some minor syntactic sugar at best. Trying to implement every other Python operator correctly, and having to have seed variables is IMO where the bulk of the complexity comes from, when trying to use Python syntax as a query language.

That's why I say that an AST literal syntax would be much more useful to me than PEP 335 for this type of use case.

As for the numeric use cases, I'm not at all clear why &, |, and ~ (or special methods/functions) aren't suitable.

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.

Actually, from a pure functionality perspective, the logical operators are shortcuts for writing if-then-else blocks, and they compile to almost the same bytecode as if-then-else blocks.

I see it as a semantic limitation that Python does not allow overriding these operators.

Python also doesn't allow overriding of 'is' or 'type()' either. I see the logical operators as being rather in the same plane of fundamentals.

More information about the Python-Dev mailing list