[Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters <thomas at python.org> wrote:
> All in all I believe I will continue to prefer specific methods for specific
> use-cases; I'm -0 on the idea of an except-expression, -0 on the syntax with
> the mandatory parentheses around the whole thing (and so far -1 on any of
> the other suggested forms.) I can see the attractiveness, but frankly, all
> the suggested changes to the stdlib fall in two categories: easier to
> express (and narrower in its exception handling) with e.g. dict.get for the
> trivial ones, or much better written out using temporary variables for the
> complex ones. As soon as an except-expression has trouble fitting on two
> lines it becomes an unsightly mess; it no longer becomes obvious what it
> does from a glance. Not having except-expr may mean we keep adding methods
> (with different names, and slightly different semantics) to cover specific
> use-cases of specific types, but I can live with that.

Most of those concerns could also be aimed at the if/else expression.
There are definitely places that do not merit its use, but that
doesn't mean the feature is a bad one. The PEP has a number of
examples that fit quite happily on a single line, and it's those that
I'm advocating. We have comprehensions, genexps, etc, etc, all (or at
least most) of which can be written out in some form of long-hand, and
it's usually better to use the short-hand - it's not just laziness,
it's expressiveness.

Speaking of the PEP, if someone could apply the latest changes, I
think it's pretty much ready for pronouncement. Thanks!

Content:
https://raw.github.com/Rosuav/ExceptExpr/master/pep-0463.txt

Diff from current peps repo:

diff -r 2cf89e9e50a3 pep-0463.txt
--- a/pep-0463.txt Tue Mar 04 18:47:44 2014 -0800
+++ b/pep-0463.txt Thu Mar 06 11:12:44 2014 +1100
@@ -250,7 +250,8 @@
 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 @@
 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 @@
 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
 =========

ChrisA