[Python-ideas] except expression

[Philipp A.]

actually i like the first proposal, because it mirrors “the trinary”:

```python
'spam' if mustard else 'eggs'
eat() except SickException else puke()
```

but it’s a bit weird.

I don’t like `return` at all, because it’s exclusively about returning from
functions. `for` is for loops. And qhile from is used more versatile, it’s
even weirder than `else` here.

I also don’t like putting anythiing but the exception type after the
`except`.

It should definitely be `EXPR except EXC_TYPE [as EXC_NAME] KEYWORD
ALT_EXPR`, with `EXC_NAME` being defined in `ALT_EXPR` and afterwards.

and i’m leaning towards `pass` or `else` as `KEYWORD`. `pass` is only used
to mean “do nothing” right now, and indeed that’s fitting: it’s just a
border between `EXC_TYPE [as EXC_NAME]` and `ALT_EXPR`, and its other
meaning makes sense in english grammar. Maybe even `try`? Like “use this,
except if that doesn’t work, then try using the other thing”.


2014-02-13 13:50 GMT+01:00 Nick Coghlan <ncoghlan at gmail.com>:

> On 13 February 2014 20:10, M.-A. Lemburg <mal at egenix.com> wrote:
> > On 13.02.2014 10:24, Nick Coghlan wrote:
> >> General comment: like Raymond, I'm inclined to favour a nice expression
> >> friendly exception handling syntax, precisely because of the
> proliferation
> >> of relatively ad hoc alternative solutions (in particular, the
> popularity
> >> of being able to pass in default values to handle empty iterables).
> >
> > Here's a variant the resembles the code you'd write in a helper
> > function to achieve the same thing, only stripped down somewhat:
> >
> > x = something() except ValueError return default_value
> >
> > def try_something():
> >     try:
> >         return something()
> >     except ValueError:
> >         return default_value
> >
> > x = something() except ValueError as exc return exc.message
> >
> > def try_something():
> >     try:
> >         return something()
> >     except ValueError as exc
> >         return exc.message
> >
> > Obviously, having a keyword "use" would make a better fit :-)
> >
> > x = something() except ValueError use default_value
>
> Even if we don't agree on a resolution for 3.5, I think there's more
> than enough interest for it to be worth someone's while to collate
> some of the proposals in a PEP - if nothing else, it will save
> rehashing the whole discussion next time it comes up :)
>
> The benefits of this:
>
> - the status quo is that various APIs are growing "default" parameters
> to handle the case where they would otherwise throw an exception
> - this is creating inconsistencies, as some such functions can be used
> easily as expressions without risking any exception (those where such
> a parameter has been added), as well as a temptation to use "Look
> Before You Leap" pre-checks, even in cases where exception handling
> would be a better choice
> - sequence indexing is a case where there is no current standard
> mechanism for providing a default value, so you're either use a
> pre-check for the system length, or else using a full try statement or
> context manager to handle the IndexError
> - by providing a clean, expression level syntax for handling a single
> except clause and providing an alternate value for the expression,
> this problem could be solved once and for all in a systematic way,
> rather than needing to incrementally change the API of a variety of
> functions (as well as addressing the container subscripting case in a
> way that doesn't require switching away from using the subscript
> syntax to a normal function call, or switching from use an expression
> to a statement)
>
>
> Some of the specific syntactic proposals:
>
>     x = op() except default if Exception
>     x = op() except default for Exception
>     x = op() except default from Exception
>     x = op() except Exception return default
>
>     x = op() except exc.attr if Exception as exc
>     x = op() except exc.attr for Exception as exc
>     x = op() except exc.attr from Exception as exc
>     x = op() except Exception as exc return exc.attr
>
> The except/if construct has parser ambiguity issues. While they're
> potentially solvable by requiring parens around conditional
> expressions in that context, that would come at the cost of a
> significant redesign of the language grammar.
>
> The except/for option reads quite nicely, but introduces a
> substantially different meaning for "for".
>
> The except/from option reads OK when combined with "as" and actually
> using the caught exception, but otherwise reads strangely.
>
> The except/return option looks like it should either introduce a new
> scope or else return from the current function. The presence of the
> "as exc" clause in all variants actually suggests a new scope could be
> a good idea, given past experience with iteration variables in list
> comprehensions.
>
> So, if we take the point of view that the new syntax is almost
> *literally* a shorthand for:
>
>     def _helper(op, exc, make_default):
>         try:
>             return op()
>         except exc:
>             return make_default()
>
>     x = _helper(op, Exception, make_default)
>
> Then that would suggest the following syntax and interpretation:
>
>     op() except Exception pass
>
>     def _work_or_return_None():
>         try:
>             return op()
>         except Exception:
>             pass
>     _work_or_return_None()
>
>     x = op() except Exception return value
>
>     def _work_or_return_default():
>         try:
>             return op()
>         except Exception:
>             return value
>     x = _work_or_return_default()
>
>     x = op() except Exception as exc return exc.attr
>
>     def _work_or_process_exception():
>         try:
>             return op()
>         except Exception as exc:
>             return exc.attr
>     x = _work_or_process_exception()
>
> OK, with the "introduces a new scope" caveat, consider me a fan of
> MAL's syntax unless/until someone points out a potential flaw that I
> have missed.
>
> A possible addition: allow "raise" in addition to "pass" and "return"
> (for exception transformation as an expression)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> 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/20140213/bf3f1f28/attachment-0001.html>