Update PEP 463 to Chris Angelico's latest (and supposedly final) version.

pep-0463.txt

@@ -250,7 +250,8 @@ expressions are evaluated lazily.  By comparison, several of the ad-hoc
 alternatives listed above must (by the nature of functions) evaluate their
 default values eagerly.  The preferred form, using the colon, parallels
 try/except by using "except exception_list:", and parallels lambda by having
-"keyword name_list: subexpression".  Using the arrow introduces a token many
+"keyword name_list: subexpression"; it also can be read as mapping Exception
+to the default value, dict-style.  Using the arrow introduces a token many
 programmers will not be familiar with, and which currently has no similar
 meaning, but is otherwise quite readable.  The English word "pass" has a
 vaguely similar meaning (consider the common usage "pass by value/reference"
@@ -271,6 +272,18 @@ with multiple except/if or with the existing if/else, or a combination.
 Using the preferred order, subexpressions will always be evaluated from
 left to right, no matter how the syntax is nested.
 
+Keeping the existing notation, but shifting the mandatory parentheses, we
+have the following suggestion::
+
+    value = expr except (Exception: default)
+    value = expr except(Exception: default)
+
+This is reminiscent of a function call, or a dict initializer.  The colon
+cannot be confused with introducing a suite, but on the other hand, the new
+syntax guarantees lazy evaluation, which a dict does not.  The potential
+to reduce confusion is considered unjustified by the corresponding potential
+to increase it.
+
 
 Example usage
 =============
@@ -854,6 +867,32 @@ there is little need of new syntax and a confusion of statement vs
 expression to achieve this.
 
 
+Common objections
+=================
+
+Colons always introduce suites
+------------------------------
+
+While it is true that many of Python's syntactic elements use the colon to
+introduce a statement suite (if, while, with, for, etcetera), this is not
+by any means the sole use of the colon. Currently, Python syntax includes
+four cases where a colon introduces a subexpression:
+
+* dict display - { ... key:value ... }
+* slice notation - [start:stop:step]
+* function definition - parameter : annotation
+* lambda - arg list: return value
+
+This proposal simply adds a fifth:
+
+* except-expression - exception list: result
+
+Style guides and PEP 8 should recommend not having the colon at the end of
+a wrapped line, which could potentially look like the introduction of a
+suite, but instead advocate wrapping before the exception list, keeping the
+colon clearly between two expressions.
+
+
 Copyright
 =========