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

Phillip J. Eby pje at telecommunity.com
Fri Sep 10 20:18:08 CEST 2004


At 12:46 AM 9/9/04 -0700, Michel Pelletier wrote:

> > Message: 4
> > Date: Fri, 10 Sep 2004 12:58:23 +1200
> > From: Greg Ewing <greg at cosc.canterbury.ac.nz>
> > Subject: [Python-Dev] ANN: PEP 335: Overloadable Boolean Operators
> > To: python-dev at python.org
> > Message-ID:
> >         <200409100058.i8A0wNIV002743 at cosc353.cosc.canterbury.ac.nz>
> >
> >
> > Python does not currently provide any '__xxx__' special methods
> > corresponding to the 'and', 'or' and 'not' boolean operators.
>
>I like the PEP with 'and' and 'or', but isn't the 'not' special method
>essentially the inverse of __nonzero__?

There isn't such a method currently.  Also, note that the expression 'not 
x' is currently guaranteed to return a boolean value.  The purpose of the 
PEP is to allow 'not x' to potentially return an arbitrary object, as for 
use in algebraic and query systems that want to use Python code as their 
syntax.  Such systems currently use e.g. '~x' instead of 'not x' because 
the former allows return of arbitrary objects.

IMO, the algebraic/query use cases would be better served by some sort of 
"code literal" or "AST literal" syntax, rather than adding more special 
methods.  The reason is that all too often you want to include "normal" 
Python values in such an expression, but still manipulate them 
symbolically, or have some other sort of special treatment.  A literal 
syntax for Python expressions is more useful for this, which is why I've 
moved to using strings and the parser module to accomplish such 
processing.  At that level, boolean operator methods are moot.

(Code literals would be useful primarily in the ability to have them parsed 
and syntax checked at import time, rather than waiting until runtime.  This 
consideration also applies to PEP 335, but PEP 335 may consume all of its 
compilation performance gains by losing runtime performance at all boolean 
operation sites.)

But anyway, I digress.  Since PEP 335 doesn't significantly help (IMO) with 
algebraic and query systems, that leaves the numeric use cases, which I 
don't have enough experience to comment on.



More information about the Python-Dev mailing list