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

Greg Ewing greg.ewing at canterbury.ac.nz
Sat May 26 03:15:45 CEST 2007

Terry Reedy wrote:

I have not seen any response to my suggestion to simplify the to-me overly baroque semantics. Missed it? Still thinking? Or did I miss something?

Sorry, I've been meaning to reply, but haven't got around to it.

Delete special casing of NotImplemented.

This is the standard way for a binary operator method to indicate that it doesn't know how to handle the types it's been given. It signals to the interpreter machinery to give the other operand a chance to handle the operation. It's a complexity already present in the system for handling binary operators, not something introduced by this proposal.

Delete NeedOtherOperand (where would it even live?)

The same place as NotImplemented, Ellipsis, etc live already.

The current spelling is True for and and False for or, as with standard semantics.

No, that's not the current spelling. The current 'and' and 'or' know nothing about True and False, only whether their operands are true or false (with a small 't').

It could possibly be used as the spelling for this purpose, but my feeling is that it would muddy the distinction between standard boolean semantics and whatever new semantics the overloaded methods are implementing -- which is supposed to be completely independent of the standard semantics.

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.

I don't agree. For example, if you're implementing operations on matrices of booleans, it seems reasonable that things like 'b and m' or 'm and b', where b is a standard boolean, should broadcast the scalar over the matrix, as with all the other binary operations. To make that work at the Python level, you need the reversed methods.

As another example, in an SQL expression builder, it doesn't seem unreasonable that mixing ordinary boolean values with SQL boolean expressions should give the expected results.

Besides, if the reversed methods weren't there, it would make these operator a special case with respect to all the others, for no apparently good reason. So while it would be a local simplification, I don't think it would simplify things overall.

Delete the 'As a special case' sentence.

That would make the spec shorter, but would make the facility more complicated to use in many cases. So again, I don't think this would be an overall simplification.

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

I don't think anyone is worried about the size of type objects -- they're not something you normally create in large quantities.

-- Greg

More information about the Python-3000 mailing list