[Python-Dev] Re: ANN: PEP 335: Overloadable Boolean Operators

[Tim Hochberg]

Greg Ewing wrote:
>>For Numeric/Numarray, I think and1/or1 would be unnecessary. If that 
>>were true in general it would simplify the proposal signifigantly: 
>>and2/or2 could be renamed to and/or and and1/or1 could be dropped.
> 
> 
> It's true that none of the use cases I put forward need and1/or1. But
> I was trying to think of the future and at least show how the general
> case could be accommodated.
> 
> Leaving out and1/or1 would make things simpler, but at the risk of
> someone coming up with a use case for them in the future, requiring
> yet another change. Wouldn't it be best to get things right from the
> beginning if possible?

Sure, assuming using and1/or1 is the right approach. I'm not convinced 
it is. I think it would be better to start with something simple, but 
design the syntax so that it can be gracefully upgraded if compelling 
use cases emerge.

My first thought on seeing the current proposal was that the special 
method names need changing. and2/or2 should be just and/or since these 
are the methods that will actually be used. I don't have a good name for 
and1/or1, but it's probably not hard to be more descriptive than the 
current names. Some imperfect possibilities: shortcircand, scand, 
preand, andsc. scand is my favorite of these. I suppose and1 could even 
be kept and only and2 renamed.

After renaming stuff, we're halfway to the simpler solution. The next 
step is, having established both that it's possible to implement full, 
custom short circuiting as per your patch and that there are no use 
cases for the custom short circuiting yet, we then just drop scand/scor 
until a compelling use case shows up, if it ever does.

> Also, the simplification wouldn't be all that great.  There would
> still be the need for two bytecodes per boolean operation to
> accommodate either short-circuiting or not. All that would be saved is
> testing for and calling the and1/or1 methods.

I'll take your word for it that the implementation would not be 
appreciably simpler. However, conceptually it's much simpler without 
__and1__/__or1__. Explaining the full version looks difficult, so why 
burden ourselves with that if we don't have to. At least not yet.

-tim