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

[Terry Reedy]

"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20705181102q29329642qb166f076d6d93999 at mail.gmail.com...
| While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
| Operators) by Greg Ewing. I am of two minds of this -- on the one
| hand, it's been a long time without any working code or anything. OTOH
| it might be quite useful to e.g. numpy folks.
|
| It is time to reject it due to lack of interest, or revive it!

Rejection would currently be fine with me, so I do not intend this to 
indicate 'revived interest'.  But having looked at the PEP now, I have some 
comments in case anyone else has such.

Rationale: if the only extra time without the overloads is the check of
Py_TPFLAGS_HAVE_BOOLEAN_OVERLOAD
then I suppose it might be 'not appreciable', but in my ignorance, I would 
be more persuaded by timing data ;-)

Motivation: another 'workaround' is the one used in symbolic logic, dating 
back to Boole himself.  '+' for 'or' and '*' for 'and'.  But these are also 
needed as in in your motivating cases.

A counter-motivation is that this proposal makes it even harder to reason 
about the behavior of Python programs.  It adds one more caveat to stick in 
the back of ones mind.  Other overloads do the same, but to me, overloading 
logic cuts a bit deeper.

Special Methods: the proposal strikes me as clever but excessively baroque. 
In the absence of justification for the complexities, here is a *much* 
simpler version.

Delete special casing of NonImplemented.

__not__: substitute for default semantics when present.

Delete NeedOtherOperand (where would it even live?).  The current spelling 
is True for and and False for or, as with standard semantics.  A class that 
does not want short circuiting, as in your motivating cases, simply defines 
__and1__  or __or1__ to return True or False.

If the return value of __xxx1__ is not True/False, then it is the result. 
(I believe this matches your spec.)  So the LOGICAL_XXX_1 bytecodes check 
for True/False identity without calling bool() on the result.

Delete the reverse methods.  They are only needed for mixed-type 
operations, like scaler*matrix.  But such seems senseless here.  In any 
case, they are not needed for any of your motivating applications, which 
would define both methods without mixing.

If the second arg is evaluated, the result is __x2__(arg1,arg2) if defined, 
else arg2 as usual.

Delete the 'As a special case' sentence.

Type Slots: someone else can decide if a new flag and 5 new slots are a 
significant price.

Python/C API: 5 more to learn or ignore, but that does not affect me.  I do 
not understand what they would do or how they relate to the byte codes.

Other Implementations: any possible problems?  (I have no idea.)

Terry Jan Reedy