PEP 758: Allow `except` and `except*` expressions without parentheses

PEPs
49

There is yet another possibility: explicitly make | a part of the except syntax (at least, if not in parentheses).

1 Like
50

This is technically backwards incompatible (though I’d be mildly surprised if anyone ever did this):

>>> class X:
...     def __or__(self, other):
...         return ZeroDivisionError
...         
>>> try:
...     1 / 0
... except X() | 42:
...     print("caught")
...     
caught
2 Likes
51

Could be initially opt-in using a __future__…

54

We have published PEP 760 – No More Bare Excepts so please redirect all the discussion about bare except handling to that thread. Thanks!

3 Likes
56

After discussing and evaluating the results of the poll, we have decided to modify PEP 758 to always require parentheses when using the “as” keyword.

The main rationale is that given that’s not very clear that there is consensus either way we have opted for keeping the parentheses requirement for as since it can be removed later if people find the disconnect too much, while taking it out and people deciding it was a bad idea doesn’t make it easy to put back.

14 Likes
57

The reference implementation is currently outdated. Also don’t forget to re-introduce the error message for capturing unparenthesized expressions.

58

We have updated it but is not giving a lot more clarity to the proposal than just the grammar section in the pep.

The full implementation will require tests docs and a bunch of extra things that won’t be done until there is a decision :slight_smile:

1 Like
59

We have submitted the PEP to the SC: PEP 758 -- Allow except and except* expressions without parentheses · Issue #281 · python/steering-council · GitHub .

1 Like
60

Sorry for being late here.

I’m definitely in favor of dropping the parentheses even when as is used. After all, if you’re not sure how as binds here relative to a comma, you can always add the parentheses if that makes you more comfortable. OTOH if you think a bit about the semantics, you will see that there is only one sensible interpretation if the parentheses are omitted – except A as a, B as b: just doesn’t make sense (how would you know whether A or B occurred without using a try/except?).

And even if you do parenthesize, it looks a bit as if you’re assigning a tuple to the as variable, which is not what’s happening, so could also be considered slightly confusing.

But if that requires first accepting this PEP and then waiting a few years until someone proposes dropping the parentheses when as is used, that’s not the end of the world either.

2 Likes
61

I’m generally on the side of “put it in the linter” whenever these debates come up, but maybe its because I find this case particularly confusing or something, I don’t think we should introduce an opportunity for ambiguity.

But even the current syntax might cause confusion among some (I hadn’t thought about the tuple thing until you mentioned it), so :person_shrugging:

62

But there is no ambiguity, except in the mind of confused users.

1 Like
63

The Python Steering Council discussed and chosen to Accept this PEP! :tada:

22 Likes