Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
C
cpython
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
cpython
Commits
e362d933
Commit
e362d933
authored
Mar 09, 2006
by
Andrew M. Kuchling
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Write a section
parent
d09def36
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
85 additions
and
1 deletion
+85
-1
Doc/whatsnew/whatsnew25.tex
Doc/whatsnew/whatsnew25.tex
+85
-1
No files found.
Doc/whatsnew/whatsnew25.tex
View file @
e362d933
...
...
@@ -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}
%======================================================================
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment