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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com