[Python-Dev] "and" and "or" operators in Py3.0
Ron Adam
rrr at ronadam.com
Tue Sep 20 18:46:43 CEST 2005
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
More information about the Python-Dev
mailing list