PEP 335: Overloadable Boolean Operators - Official Posting

[Greg Ewing]

Gerrit wrote:
> I like the idea but I don't like the method names. I don't like numbers
> in method names, since they don't intuitively tell the user about what
> it does. In my opinion, and1 should be called and, or1 or, rand2 rand
> and ror2 ror. The only two left are then and2 and or2.

I think it would be very confusing to have numbers in *some*
method names but not others, with little rhyme or reason as
to which.

The names I chose use the numbers in a very systematic way:
The 1 methods are called during phase 1 and have 1 operand;
the 2 methods are called during phase 2 and have 2 operands.

I'm open to suggestions about alternative naming schemes,
but your suggestion doesn't seem like an improvement to me.

> Another
> possibility: always have a second argument in and, and default it to
> None. It can return NeedOtherOperand or similar if it needs, and ignore
> it otherwise.

That would require all implementations of these methods to
do a dance to cope with None as the second argument, even
when there was no interest in short-circuiting. I'm not
convinced there's a net gain in elegance.

> What happens if an object defines only rand2? Does it depend on the left
> operand to be called, or is it always called? E.g. can the right operand
> influence short-circuiting (I assume not)?

Obviously not, since that would require the right operand to
be evaluated in order to determine whether to evaluate the
right operand - kind of a catch-22.

This seems to be an inescapable consequence of having short
circuiting at all. Some things can only be controlled by the
left operand.

-- 
Greg Ewing, Computer Science Dept,
University of Canterbury,	
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg