[Python-Dev] "and" and "or" operators in Py3.0

[Ron Adam]

Fredrik Lundh wrote:
> Michael Hudson wrote:
> 
> 
>>>While you're at it, maybe we should switch to && and || as well?
>>>That's another thing I always mistype when switching between
>>>languages...
>>
>>You're joking, surely?
> 
> 
> for Python 3000, I'd recommend switching to "and then" and "or else" instead
> of the current ambiguous single-keyword versions.
> 
> </F> 

Keeping the current behaviors in some form would probably be good. 
Alternate operators might be a good way.

They could also be functions.

      first_true(a, b, c)  <---   a and b and d
      true_else(a, b)      <---   a or b

This would compliment:

      all_true(a, b, c)
      none_true(a, b, c)



The '?' could just be used in place of the current 'or' and the '*' 
would work as "and value" operator when used with bools.

     val = a ? b ? c        # val = a or b or c

     val = a and b * c      # val = bool(a and b) and c

     val = a or b * c ? d   # val = bool(a or b) and c or d



And a vague idea of a suggestion...

For the function versions above ... If speed or the need to avoid early 
evaluation is a concern, one thought would be to have a few "well 
selected" builtin C tuple operators that look and act like functions but 
are instead optimized operations.

Functions that don't use any intermediate values and/or are so simple 
that the function call is large percent of the overall execution time 
could be candidates.

It also might be possible to avoid early evaluation in cases where it 
makes since to do so.

Just a thought.  I have no idea how hard this would be, and since one of 
the goals of Python 3000 is to simplify and/or clean up the core, this 
might not be desirable.

Cheers,
Ron