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

[Greg Ewing]

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