[Python-Dev] ANN: PEP 335: Overloadable Boolean Operators
Phillip J. Eby
pje at telecommunity.com
Wed Sep 15 05:15:37 CEST 2004
At 01:15 PM 9/15/04 +1200, Greg Ewing wrote:
>"Phillip J. Eby" <pje at telecommunity.com>:
> > So, something like this:
> > query("x and y or z")
> > isn't "code that performs database queries"?
>Yes, but it's not Python code - it's SQL code wrapped
>in a string wrapped in Python code. I want just Python
But if this were possible:
query(``x and y or z``)
such that the expression ``x and y or z`` results in a Python AST for that
expression, then you'd be able to do whatever you want with it.
> > 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.
>The overhead shouldn't be substantially worse than that already
>incurred by all the other operators being overloadable. Also,
>realistically, how much code do you think has boolean operations as a
>speed bottleneck? I find it hard to imagine what such code would be
So it's acceptable to slow down all logical operations, add new byte codes,
and expand the size of the eval loop, all to support a niche usage? That
doesn't make sense to me.
Again, I'm not familiar with the numeric use cases, but I am familiar with
algebraic manipulation of Python code for SQL generation and other
purposes, and I honestly don't see any benefit to the PEP for those
purposes. AST's are more useful, and I'd support a PEP to make code
expressible as literals, because that wouldn't impose overhead on systems
that doesn't use them. (For one thing, they could be expressed as
constants in code objects, so the bytecode would just be LOAD_CONST.)
For the numeric use cases, frankly I don't see why one would want to apply
short-circuiting boolean operators to arrays, since presumably the values
in them have already been evaluated.
And if the idea is to make them *not* be short-circuting operators, that
seems to me to corrupt the whole point of the logical operators versus
their bitwise counterparts.
More information about the Python-Dev