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

[Phillip J. Eby]

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.