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

[Thomas Wouters]

On Wed, Mar 5, 2014 at 4:28 PM, Chris Angelico <rosuav at gmail.com> wrote:

> 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.
>

And I did :) But the if-else expression had a single thing going for it,
the thing that landed the actual feature: it prevents people from using
buggy alternatives in the quest for short code, the and-or trick. You may
remember that Guido initially rejected the if-else expression, until he
realized people were going to use something like it whether he liked it or
not. The except-expression has a different issue: people catching
exceptions too broadly. I don't believe that's as big a problem, nor is it
as subtly wrong. And the except-expression doesn't solve _all_ such issues,
just a very small subset. It's just another thing to learn when you're new,
and just another thing to consider when reviewing code.


> 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.
>

It's not a question of it being expressive, it's a question of it being
worth separate syntax. I don't think it's worth syntax.


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

PEP update pushed (changeset 59653081cdf6.)


>
> 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/thomas%40python.org
>



-- 
Thomas Wouters <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140305/f96bd7bd/attachment.html>