PEP308: Yet another syntax proposal

[James J. Besemer]

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