[Python-3000] Wither PEP 335 (Overloadable Boolean Operators)? (original) (raw)

Neville Grech Neville Grech nevillegrech at gmail.com
Fri May 25 11:25:17 CEST 2007

From a user's POV, I'm +1 on having overloadable boolean functions. In many cases I had to resort to overload add or neg instead of and & not, I foresee a lot of cases where the and overload could be used to join objects which represent constraints. Overloadable boolean operators could also be used to implement other types of logic (eg: fuzzy logic). Constraining them to just primitive binary operations in my view will be delimiting for a myriad of use cases.

Sure, in some cases, one could overload the neg operator instead of the not but semantically they have different meanings.

On 5/25/07, Guido van Rossum <guido at python.org> wrote:

On 5/24/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > 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 > a bit. > > 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: > > > into > > > JUMPIFFALSE L1 > POPTOP > > JUMPIFFALSE L1 > POPTOP > > JUMPFORWARD L2 > L1: > 15 POPTOP > L2: > > Under my PEP, without any other changes, this would become > > > LOGICALAND1 L1 > > LOGICALAND2 > L1: > JUMPIFFALSE L2 > POPTOP > > JUMPFORWARD L3 > L2: > 15 POPTOP > L3: > > The fastest path through this involves executing one extra > bytecode. However, since we're not using JUMPIFFALSE 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 POPJUMPIFFALSE. This allows us to > get rid of all the POPTOPs, plus the jump at the end of > the statement body. Now we have > > > LOGICALAND1 L1 > > LOGICALAND2 > L1: > POPJUMPIFFALSE L2 > > L2: > > 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: > > > becomes > > > LOGICALOR1 L1 > > LOGICALAND1 L2 > > LOGICALAND2 > L2: > LOGICALOR2 > L1: > POPJUMPIFFALSE L3 > > L3: > > 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 > it. Do you have an implementation available to measure this? In most cases the cost is not in the number of bytecode instructions executed but in the total amount of work. Two cheap bytecodes might well be cheaper than one expensive one. However, I'm happy to keep your PEP open until you have code that we can measure. (However, adding additional optimizations elsewhere to make up for the loss wouldn't be fair -- we would have to compare with a 2.5 or trunk (2.6) interpreter with the same additional optimizations added.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Python-3000 mailing list Python-3000 at python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com

-- Regards, Neville Grech -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-3000/attachments/20070525/8c88dbf1/attachment.html

More information about the Python-3000 mailing list