From a526eed9cbf510acbc367b28f25caa1de2a576c1 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Fri, 7 Feb 2003 17:03:31 +0000 Subject: [PATCH] Add PEP 308: if-then-else expression proposal. --- pep-0000.txt | 2 + pep-0308.txt | 113 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 115 insertions(+) create mode 100644 pep-0308.txt diff --git a/pep-0000.txt b/pep-0000.txt index aca58ac80..c1f3effa4 100644 --- a/pep-0000.txt +++ b/pep-0000.txt @@ -109,6 +109,7 @@ Index by Category I 305 CSV File API Montanaro, et al I 306 How to Change Python's Grammar Hudson S 307 Extensions to the pickle protocol GvR, Peters + S 308 If-then-else expression GvR Finished PEPs (done, implemented in CVS) @@ -306,6 +307,7 @@ Numerical Index I 305 CSV File API Montanaro, et al I 306 How to Change Python's Grammar Hudson S 307 Extensions to the pickle protocol GvR, Peters + S 308 If-then-else expression GvR SR 666 Reject Foolish Indentation Creighton diff --git a/pep-0308.txt b/pep-0308.txt new file mode 100644 index 000000000..5239cf751 --- /dev/null +++ b/pep-0308.txt @@ -0,0 +1,113 @@ +PEP: 308 +Title: If-then-else expression +Version: $Revision$ +Last-Modified: $Date$ +Author: Guido van Rossum +Status: Active +Type: Standards Track +Content-Type: text/plain +Created: 7-Feb-2003 +Post-History: 7-Feb-2003 + + +Introduction + + Requests for an if-then-else ("ternary") expression keep coming up + on comp.lang.python. This PEP contains a concrete proposal of a + fairly Pythonic syntax. This is the community's one chance: if + this PEP is approved with a clear majority, it will be implemented + in Python 2.4. If not, the PEP will be augmented with a summary + of the reasons for rejection and the subject better not come up + again. While I am the author of this PEP, I am neither in favor + nor against this proposal; it is up to the community to decide. + If the community can't decide, I'll reject the PEP. + + +Proposal + + The proposed syntax is as follows: + + if else + + This is evaluated like this: + + - First, is evaluated. + + - If is true, is evaluated and is the + result of the whole thing. + + - If is false, is evaluated and is the + result of the whole thing. + + Note that at most one of and is + evaluated. This is called a "shortcut expression"; it is similar + to the way the second operand of 'and' / 'or' is only evaluated if + the first operand is true / false. + + To disambiguate this in the context of other operators, the + "if...else" part in the middle acts like a left-associative binary + operator with a priority lower than that of "or", and higher than + that of "lambda". + + Examples of how this works out: + + x if C else y if D else z <==> x if C else (y if D else z) + x or y if C else z <==> (x or y) if C else z + x if C else y or z <==> x if C else (y or z) + lambda: x if C else y <==> lambda: (x if C else y) + x if C else lambda: y <==> SyntaxError + x if C else y, z <==> (x if C else y), z + x, y if C else z <==> x, (y if C else z) + + +Alternatives + + Many C-derived languages use this syntax: + + ? : + + I reject this for several reasons: the colon already has many uses + in Python (even though it would actually not be ambiguous, because + the question mark requires a matching colon); for people not used + to C-derived language, it is hard to understand. + + + Eric Raymond proposed a variant that doesn't have this problem: + + ? ! + + While cute, this suffers from the Perlish problem of using + arbitrary punctuation with an arbitrary meaning; and it's no + easier to understand than the ?: form. + + + If we could live with adding a new keyword, we could use: + + if then else + + Apart from the problem of introducing a new keyword for a minor + feature, this also suffers from ambiguity at the start of a + statement; for example: + + if verbose then sys.stdout.write("hello\n") else None + + could be an syntactically correct expression statement, but starts + with 'if', which makes the parser believe it is the start of an + 'if' statement. To resolve this, the syntax would have to require + parentheses, which makes it uglier. However, this form has the + advantage of evaluating strictly from left to right (not that that + is a requirement for being Pythonic -- list comprehensions don't). + + +Copyright + + This document has been placed in the public domain. + + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +sentence-end-double-space: t +fill-column: 70 +End: