"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
