PEP308: Yet another syntax proposal
James J. Besemer
jb at cascade-sys.com
Tue Feb 11 01:21:15 EST 2003
Dennis Lee Bieber wrote:
>
> <satanic-counsel> "And" and "Or" are technically isolated to the
> evaluation of a condition, and not to the processing of alternatives
> (if any) selected by the result of the condition. In normal languages
"normal languages" ?
> which offer short-circuiting the result of the condition is strictly a
> Boolean; it is only because of the Python semantics which result in
> returning the actual object which was last evaluated rather than
> True/False which even made the work-around possible.
C/C++ and some others return boolean.
LISP long ago defined AND and OR in a Python-like fashion where the argument
was returned instead of a boolean value. LISP also defined a COND operator
which was much like the present if/elif/else expression proposal kicking around.
> Therefore there is
> no valid precedent for using late-binding/lazy-evaluation of the
> branches selected by a condition.
If I understand what you're saying, LISP established such a precedent, like,
30 years ago.
If you meant to say there is no precedence for evaluating both terms of a
conditional expression operator, I think that MIGHT be closer to the truth.
> <defense> Normally blocked if:/else: sequence do not evaluate the
> non-selected branch. Since an inline if is meant to shorten
>
> if cond:
> v = e1
> else:
> v = e2
>
> into a single
>
> v = <TBD SYNTAX>
>
> it is reasonable to presume that unselected brances will not be
> evaluated.</defense>
That seems reasonable to me.
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:jb at cascade-sys.com
http://cascade-sys.com
More information about the Python-list
mailing list