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

[Phillip J. Eby]

At 02:58 PM 9/14/04 +1200, Greg Ewing wrote:
> > IMO, the algebraic/query use cases would be better served by some
> > sort of "code literal" or "AST literal" syntax
>
>You may be right about the symbolic algebra case, if the intent is to
>be able to write code that manipulates expressions, in which case
>writing the expressions to be manipulated as literals of some kind may
>make sense.
>
>But I don't agree in the SQL case, where my intent is for the user to
>simply write Python code that performs database queries, not write
>Python code that constructs trees of SQL expressions that perform
>database queries.

So, something like this:

      query("x and y or z")

isn't "code that performs database queries"?

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.  I also fear that as a result, people will start writing complex 
if-then blocks to "optimize" performance of conditionals to get them back 
to where they were before the facility was added.  Also, it considerably 
expands the scope of understanding that someone needs in order to grasp the 
meaning of a logical expression.

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).