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

[Neville Grech Neville Grech]

>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:
> >      <stats>
> >
> > into
> >
> >      <evaluate a>
> >      JUMP_IF_FALSE L1
> >      POP_TOP
> >      <evaluate b>
> >      JUMP_IF_FALSE L1
> >      POP_TOP
> >      <stats>
> >      JUMP_FORWARD L2
> >    L1:
> >      15 POP_TOP
> >    L2:
> >
> > Under my PEP, without any other changes, this would become
> >
> >      <evaluate a>
> >      LOGICAL_AND_1 L1
> >      <evaluate b>
> >      LOGICAL_AND_2
> >    L1:
> >      JUMP_IF_FALSE L2
> >      POP_TOP
> >      <stats>
> >      JUMP_FORWARD L3
> >    L2:
> >      15 POP_TOP
> >    L3:
> >
> > 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
> >
> >      <evaluate a>
> >      LOGICAL_AND_1 L1
> >      <evaluate b>
> >      LOGICAL_AND_2
> >    L1:
> >      POP_JUMP_IF_FALSE L2
> >      <stats>
> >    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:
> >      <stats>
> >
> > becomes
> >
> >      <evaluate a>
> >      LOGICAL_OR_1 L1
> >      <evaluate b>
> >      LOGICAL_AND_1 L2
> >      <evaluate c>
> >      LOGICAL_AND_2
> >    L2:
> >      LOGICAL_OR_2
> >    L1:
> >      POP_JUMP_IF_FALSE L3
> >      <stats>
> >    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-dev/attachments/20070525/8c88dbf1/attachment.htm