[Python-Dev] Wither PEP 335 (Overloadable Boolean Operators)?
greg.ewing at canterbury.ac.nz
Fri May 25 04:05:35 CEST 2007
Guido van Rossum wrote:
> Last call for discussion! I'm tempted to reject this -- the ability to
> generate optimized code based on the shortcut semantics of and/or is
> pretty important to me.
Please don't be hasty. I've had to think about this issue
The conclusion I've come to is that there may be a small loss
in the theoretical amount of optimization opportunity available,
but not much. Furthermore, if you take into account some other
improvements that can be made (which I'll explain below) the
result is actually *better* than what 2.5 currently generates.
For example, Python 2.5 currently compiles
if a and b:
Under my PEP, without any other changes, this would become
The fastest path through this involves executing one extra
bytecode. However, since we're not using JUMP_IF_FALSE to
do the short-circuiting any more, there's no need for it
to leave its operand on the stack. So let's redefine it and
change its name to POP_JUMP_IF_FALSE. This allows us to
get rid of all the POP_TOPs, plus the jump at the end of
the statement body. Now we have
The fastest path through this executes one *less* bytecode
than in the current 2.5-generated code. Also, any path that
ends up executing the body benefits from the lack of a
jump at the end.
The same benefits also result when the boolean expression is
more complex, e.g.
if a or b and c:
which contains 3 fewer instructions overall than the
corresponding 2.5-generated code.
So I contend that optimization is not an argument for
rejecting this PEP, and may even be one for accepting
More information about the Python-Dev