summaryrefslogtreecommitdiffstats
path: root/Doc/whatsnew
diff options
context:
space:
mode:
authorAndrew M. Kuchling <amk@amk.ca>2006-03-09 13:56:25 (GMT)
committerAndrew M. Kuchling <amk@amk.ca>2006-03-09 13:56:25 (GMT)
commite362d9336704f80493875e6ad665fc554a903049 (patch)
tree884f1afd23abff1460cd0003f991e5b98a427593 /Doc/whatsnew
parentd09def36d52af3e087433eb67c49da633436c602 (diff)
downloadcpython-e362d9336704f80493875e6ad665fc554a903049.zip
cpython-e362d9336704f80493875e6ad665fc554a903049.tar.gz
cpython-e362d9336704f80493875e6ad665fc554a903049.tar.bz2
Write a section
Diffstat (limited to 'Doc/whatsnew')
-rw-r--r--Doc/whatsnew/whatsnew25.tex86
1 files changed, 85 insertions, 1 deletions
diff --git a/Doc/whatsnew/whatsnew25.tex b/Doc/whatsnew/whatsnew25.tex
index 1d88f4f..8645e32 100644
--- a/Doc/whatsnew/whatsnew25.tex
+++ b/Doc/whatsnew/whatsnew25.tex
@@ -29,7 +29,91 @@ rationale, refer to the PEP for a particular new feature.
%======================================================================
\section{PEP 308: Conditional Expressions}
-% XXX write this
+For a long time, people have been requesting a way to write
+conditional expressions, expressions that return value A or value B
+depending on whether a Boolean value is true or false. A conditional
+expression lets you write a single assignment statement that has the
+same effect as the following:
+
+\begin{verbatim}
+if condition:
+ x = true_value
+else:
+ x = false_value
+\end{verbatim}
+
+There have been endless tedious discussions of syntax on both
+python-dev and comp.lang.python, and even a vote that found the
+majority of voters wanted some way to write conditional expressions,
+but there was no syntax that was clearly preferred by a majority.
+Candidates include C's \code{cond ? true_v : false_v},
+\code{if cond then true_v else false_v}, and 16 other variations.
+
+GvR eventually chose a surprising syntax:
+
+\begin{verbatim}
+x = true_value if condition else false_value
+\end{verbatim}
+
+Evaluation is still lazy as in existing Boolean expression, so the
+evaluation jumps around a bit. The \var{condition} expression is
+evaluated first, and the \var{true_value} expression is evaluated only
+if the condition was true. Similarly, the \var{false_value}
+expression is only evaluated when the condition is false.
+
+This syntax may seem strange and backwards; why does the condition go
+in the \emph{middle} of the expression, and not in the front as in C's
+\code{c ? x : y}? The decision was checked by applying the new syntax
+to the modules in the standard library and seeing how the resulting
+code read. In many cases where a conditional expression is used, one
+value seems to be the 'common case' and one value is an 'exceptional
+case', used only on rarer occasions when the condition isn't met. The
+conditional syntax makes this pattern a bit more obvious:
+
+\begin{verbatim}
+contents = ((doc + '\n') if doc else '')
+\end{verbatim}
+
+I read the above statement as meaning ``here \var{contents} is
+usually assigned a value of \code{doc+'\n'}; sometimes
+\var{doc} is empty, in which special case an empty string is returned.''
+I doubt I will use conditional expressions very often where there
+isn't a clear common and uncommon case.
+
+There was some discussion of whether the language should require
+surrounding conditional expressions with parentheses. The decision
+was made to \emph{not} require parentheses in the Python language's
+grammar, but as a matter of style I think you should always use them.
+Consider these two statements:
+
+\begin{verbatim}
+# First version -- no parens
+level = 1 if logging else 0
+
+# Second version -- with parens
+level = (1 if logging else 0)
+\end{verbatim}
+
+In the first version, I think a reader's eye might group the statement
+into 'level = 1', 'if logging', 'else 0', and think that the condition
+decides whether the assignment to \var{level} is performed. The
+second version reads better, in my opinion, because it makes it clear
+that the assignment is always performed and the choice is being made
+between two values.
+
+Another reason for including the brackets: a few odd combinations of
+list comprehensions and lambdas could look like incorrect conditional
+expressions. See \pep{308} for some examples. If you put parentheses
+around your conditional expressions, you won't run into this case.
+
+
+\begin{seealso}
+
+\seepep{308}{Conditional Expressions}{PEP written by
+Guido van Rossum and Raymond D. Hettinger; implemented by Thomas
+Wouters.}
+
+\end{seealso}
%======================================================================