[Python-Dev] Wither PEP 335 (Overloadable Boolean Operators)?
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
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*
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
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