[Python-Dev] ANN: PEP 335: Overloadable Boolean Operators
Phillip J. Eby
pje at telecommunity.com
Tue Sep 14 06:37:06 CEST 2004
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).
More information about the Python-Dev
mailing list