[Python-ideas] except expression

[Nick Coghlan]

On 19 Feb 2014 07:20, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 18 February 2014 20:55, Chris Angelico <rosuav at gmail.com> wrote:
> > Alright, results are in.
> >
> > Script:
> > https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py
> > Output:
> > https://github.com/Rosuav/ExceptExpr/blob/master/candidates.txt
> > Annotated examples:
> > https://github.com/Rosuav/ExceptExpr/blob/master/examples.py
>
> Great work!

Indeed!

On the syntax front, one option to keep in mind is the "yield expression"
solution: require the surrounding parentheses, except when it is used as a
standalone statement, as the sole expression on the RHS of an assignment
statement, or (perhaps) as the sole positional argument to a function call.
That approach keeps the simple cases clean, while making more complex cases
a bit easier to read.

>
> Looking at the annotated examples, my conclusions would be:
>
> 1. The "expr except Exception: default" syntax is actually a lot more
> readable in context than I expected.
> 2. But sometimes in more complex cases the similarity with the
> statement form hurts readability.
> 3. The win is noticeable on the one-line assignments
> 4. You had a few cases where you could have (should have?) translated
> to 3-arg getattr or similar. I'm not quite sure what that says ("if
> you have a hammer everything looks like a nail"?)
> 5. The longer examples typically look more confusing to me than the
originals.
> 6. As you noted, nothing much used multiple exceptions or as. I think
> this implies they are of marginal benefit at best (but I'm guessing
> just as much as you).

I think it's worth keeping the name binding (since that would be very hard
to add later), but restricting the initial proposal to a single except
clause would make sense. Without the block structure to help, it is awfully
difficult to associate multiple except clauses with their corresponding
initial expression, and if you really want to have different results for
different exceptions, you can pass the caught exception to a translator
function.

>
> Based on this sample, my main worry with the new syntax is that people
> will over-use it. Up to line 125 of the examples I'd say about 50%
> seem like wins. After that point the only ones I like are
> Lib/tarfile.py and Tools/unicode/comparecodecs.py.

This was one of the main concerns with PEP 308 as well, and the general
principle of "use it only if it helps readability" seems to have kept that
under control.

> Overall, I think this is a reasonable case for the PEP, but it's not
> overwhelming. Which I guess about mirrors my gut feeling for how
> useful the new construct would be.

As with PEP 308, I think this is more about the existing workarounds for
the lack of a language level solution causing enough problems that the new
syntax is being suggested primarily to say "stop doing that!".

Cheers,
Nick.

>
> Paul
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140219/152b4dbe/attachment.html>