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

Terry Reedy tjreedy at udel.edu
Sat May 19 04:10:18 CEST 2007

"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

More information about the Python-Dev mailing list