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

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

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

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 mailing list