[Python-Dev] ANN: PEP 335: Overloadable Boolean Operators

[Phillip J. Eby]

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.