[Python-Dev] Re: PEP 654 except* formatting

Rob Cliffe is having problems posting to the Python-Dev list, so he posted an alternative suggestion to the Python-Ideas list: https://mail.python.org/archives/list/python-id...@python.org/message/6KQUQBKFGJSGDNXFZBSM5OXD2ISLIQTT/ Rob's idea is to use "except for ..." with exception groups,

[Python-Dev] Re: PEP 654 except* formatting

On 06/10/2021 17:35, Łukasz Langa wrote: > >> On 6 Oct 2021, at 18:05, Yury Selivanov wrote: [...] >> I'll list a few reasons here: >> >> 1. `try: .. except group:` is a valid syntax today. And it will continue to >> be valid syntax. Having both `try: .. except group:` (catch exception >>

[Python-Dev] Re: PEP 654 except* formatting

try:     ... except group (KeyError, ZeroDivisionError) as error:     ... With the precedence you suggest, now group(...) becomes a function call. On 06/10/2021 15:36, Łukasz Langa wrote: >> On 6 Oct 2021, at 16:01, Petr Viktorin wrote: >> >> What about this: >> >> group =

[Python-Dev] Re: PEP 654 except* formatting

How about "except_group", or "exceptgroup"? That's definitely not ambiguous, and can certainly work as a soft keyword. On 06/10/2021 11:06, Larry Hastings wrote: > > It seems like, for this to work, "group" would have to become a keyword.  > This would play havoc with a lot of existing code.  I

[Python-Dev] Re: PEP 654 except* formatting

Yury Selivanov wrote: > IMO it would make more sense to write `except all E`, > but `all()` is a built-in and so this would be at > odds with (1). [`try: .. except group:` already being valid > syntax today ] If anything, that makes "except all E" less of a problem; the built-in all is not an

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 18:48, Guido van Rossum wrote: > > On Wed, Oct 6, 2021 at 9:01 AM Brandt Bucher > wrote: > Another option (to remove the ambiguity) could be to move the “group” after > the expression. Bonus points for reading more clearly: > > except

[Python-Dev] Re: PEP 654 except* formatting

On Wed, Oct 6, 2021 at 9:01 AM Brandt Bucher wrote: > Another option (to remove the ambiguity) could be to move the “group” > after the expression. Bonus points for reading more clearly: > > except MemoryError group as e: … > except (KeyError, IndexError) group as e: … > except some + expression

[Python-Dev] Re: PEP 654 except* formatting

Just my two small cents: soft keywords have a cost as they make everything around them more complicated in the parser. For example, creating custom error messages around soft keywords is one or two levels of magnitude more complicated as sometimes you need to parse segments of syntactically

[Python-Dev] Re: PEP 654 except* formatting

On Wed, Oct 6, 2021 at 12:01 PM Brandt Bucher wrote: > Łukasz Langa wrote: > > Joking aside, since we allow any expression after 'except' 'group' then > this is indeed ambiguous. In theory! > > Another option (to remove the ambiguity) could be to move the “group” > after the expression. Bonus

[Python-Dev] Re: PEP 654 except* formatting

How about ``` try: ... exceptgroup E1, E2: ... `` ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at

[Python-Dev] Re: PEP 654 except* formatting

On 10/6/2021 5:05 PM, Yury Selivanov wrote: So I'm -1 on `except group` or any variant that uses soft keywords. If the SC considers making `group` a proper keyword I can possibly change my mind on this. For the record (and I'm sure I'm not the only one), I'm -100 on making it a proper

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 18:05, Yury Selivanov wrote: > > I don't like `except group` or any variant with soft keywords. As Brandt just commented, this proposal is a no go due to confusion with function calls. I'll respond below anyway because looking through it was an interesting experience >

[Python-Dev] Re: PEP 654 except* formatting

That might be exceptable. -Barry > On Oct 6, 2021, at 08:59, Brandt Bucher wrote: > > Łukasz Langa wrote: >> Joking aside, since we allow any expression after 'except' 'group' then this >> is indeed ambiguous. In theory! > > Another option (to remove the ambiguity) could be to move the

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 18:14, Brandt Bucher wrote: > > Łukasz Langa wrote: >> Joking aside, since we allow any expression after 'except' 'group' then this >> is indeed ambiguous. In theory! > > The ambiguity with function calls, though, is probably a dealbreaker: > > except group (E1, E2) as e:

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 18:13, Larry Hastings wrote: > On 10/6/21 2:34 PM, Łukasz Langa wrote: > >> We can even make its error message smarter than the default NameError, since >> -- as I claim -- it's terribly unlikely somebody would mean to name their >> dynamic exception collection "group". >

[Python-Dev] Re: PEP 654 except* formatting

Łukasz Langa wrote: > Joking aside, since we allow any expression after 'except' 'group' then this > is indeed ambiguous. In theory! The ambiguity with function calls, though, is probably a dealbreaker: except group (E1, E2) as e: … except group(E1, E2) as e: … See my other message for an

[Python-Dev] Re: PEP 654 except* formatting

On Wed, 6 Oct 2021 09:05:57 -0700 Yury Selivanov wrote: > > So I'm -1 on `except group` or any variant that uses soft keywords. If the > SC considers making `group` a proper keyword I can possibly change my mind > on this. How about a dedicated keyword such as "exceptany" or "exceptall"?

[Python-Dev] Re: PEP 654 except* formatting

On 10/6/21 2:34 PM, Łukasz Langa wrote: On 6 Oct 2021, at 12:06, Larry Hastings > wrote: It seems like, for this to work, "group" would have to become a keyword. No, just like `match` and `case` didn't have to. This would play havoc with a lot of existing code.

[Python-Dev] Re: PEP 654 except* formatting

I don't like `except group` or any variant with soft keywords. I'll list a few reasons here: 1. `try: .. except group:` is a valid syntax today. And it will continue to be valid syntax. Having both `try: .. except group:` (catch exception `group`) and `try: .. except group E:` (catch exceptions

[Python-Dev] Re: PEP 654 except* formatting

Łukasz Langa wrote: > Joking aside, since we allow any expression after 'except' 'group' then this > is indeed ambiguous. In theory! Another option (to remove the ambiguity) could be to move the “group” after the expression. Bonus points for reading more clearly: except MemoryError group as e:

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 16:01, Petr Viktorin wrote: > > What about this: > > group = (KeyboardInterrupt, MemoryError) > other_group = (KeyError, IndexError) > > try: > ... > except group + other_group as error: > ... Haha, let's see if we can write a Mersienne twister all inside an except

[Python-Dev] Re: PEP 654 except* formatting

On 06. 10. 21 15:34, Łukasz Langa wrote: On 6 Oct 2021, at 12:06, Larry Hastings > wrote: It seems like, for this to work, "group" would have to become a keyword. No, just like `match` and `case` didn't have to. This would play havoc with a lot of existing

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 12:06, Larry Hastings wrote: > > It seems like, for this to work, "group" would have to become a keyword. > No, just like `match` and `case` didn't have to. > This would play havoc with a lot of existing code. > Extraordinary claims require extraordinary evidence, Larry.

[Python-Dev] Re: PEP 654 except* formatting

It seems like, for this to work, "group" would have to become a keyword.  This would play havoc with a lot of existing code.  I can't tell you how many times I've used the identifier "group" in my code, particularly when dealing with regular expressions. Even making it a soft keyword, a la

[Python-Dev] Re: PEP 654 except* formatting

On 10/5/21 6:32 PM, MRAB wrote: > On 2021-10-06 02:12, Barry Warsaw wrote: >> What do the PEP authors think about `except group`? Bikeshedding aside, that’s still the best alternative I’ve seen. >> It’s unambiguous, self-descriptive, and can’t be confused with unpacking syntax. >> > +1 +1

[Python-Dev] Re: PEP 654 except* formatting

On 2021-10-06 02:12, Barry Warsaw wrote: What do the PEP authors think about `except group`? Bikeshedding aside, that’s still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and can’t be confused with unpacking syntax. +1 ___

[Python-Dev] Re: PEP 654 except* formatting

What do the PEP authors think about `except group`? Bikeshedding aside, that’s still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and can’t be confused with unpacking syntax. -Barry > On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev > wrote: > > I agree

[Python-Dev] Re: PEP 654 except* formatting

What do the PEP authors think about `except group`? Bikeshedding aside, that’s still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and can’t be confused with unpacking syntax. -Barry > On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev > wrote: > > I agree

[Python-Dev] Re: PEP 654 except* formatting

On Tue, Oct 05, 2021 at 11:17:25AM -0400, Calvin Spealman wrote: > On Tue, Oct 5, 2021 at 10:51 AM Patrick Reader <_...@pxeger.com> wrote: > > > On 03/10/2021 16:47, Irit Katriel via Python-Dev wrote: > > > > 1. except *E as e: // except *(E1, E2) as e: > > 2. except* E as e: // except* (E1,

[Python-Dev] Re: PEP 654 except* formatting

On 6/10/21 7:15 am, sascha.schlemmer--- via Python-Dev wrote: except (*E1, *E2) as error: ... Then we would have to decide whether to allow except (E1, *E2) as error: ... and if so, what it would mean. -- Greg ___ Python-Dev mailing list --

[Python-Dev] Re: PEP 654 except* formatting

I agree that *(E1, E2) looks like unpacking, how about except *E1 as error: ... except (*E1, *E2) as error: ... even better would be if we could drop the braces: except *E1, *E2 as error: ... ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] Re: PEP 654 except* formatting

On Tue, Oct 5, 2021 at 10:51 AM Patrick Reader <_...@pxeger.com> wrote: > On 03/10/2021 16:47, Irit Katriel via Python-Dev wrote: > > 1. except *E as e: // except *(E1, E2) as e: > 2. except* E as e: // except* (E1, E2) as e: > > I vote #2, because `except *(e1, e2) as e:` could imply that

[Python-Dev] Re: PEP 654 except* formatting

On 03/10/2021 16:59, Patrick Reader wrote: > On 03/10/2021 16:47, Irit Katriel via Python-Dev wrote: >>> 1. except *E as e:  //  except *(E1, E2) as e: >>> 2. except* E as e:  //  except* (E1, E2) as e: > > I vote #2, because `except *(e1, e2) as e:` could imply that this is > splatting an

[Python-Dev] Re: PEP 654 except* formatting

On 03/10/2021 16:54, Thomas Grainger wrote: > What about `except case ExceptionGroup[E1 | E2]:`? and use match semantics? > > On Sun, 3 Oct 2021, 16:50 Irit Katriel via Python-Dev, > wrote: > > > We wonder if people have a view on which of the following is > clearer/better: >> 1. except

[Python-Dev] Re: PEP 654 except* formatting

On 03/10/2021 16:47, Irit Katriel via Python-Dev wrote: >> 1. except *E as e:  //  except *(E1, E2) as e: >> 2. except* E as e:  //  except* (E1, E2) as e: I vote #2, because `except *(e1, e2) as e:` could imply that this is splatting an arbitrary expression there - it looks like it will match

[Python-Dev] Re: PEP 654 except* formatting

On Mon, Oct 04, 2021 at 07:31:10PM +0100, Steve Dower wrote: > To me, the "*name" looks most similar to how we write "*args" in a > function definition, so I'd go for that. That's exactly why we *shouldn't* go for that option. That is going to confuse a lot of people that it is sequence

[Python-Dev] Re: PEP 654 except* formatting

On 10/4/2021 9:57 AM, Ammar Askar wrote: Throwing in another +1 for `except group`. It's explicit, doesn't introduce new punctuation and avoids confusion with unpacking. I agree for same reasons. And avoids more bikeshedding. I checked and if 'except group' is added to keyword.kwlist

[Python-Dev] Re: PEP 654 except* formatting

On 04/10/2021 00:57, Barry Warsaw wrote: On Oct 3, 2021, at 10:42, Łukasz Langa wrote: Speaking just for myself, the `except *` syntax always bothered me, but I couldn’t come up with anything better and it wasn’t enough for me to vote against PEP 654. `except group` is nicer though, and

[Python-Dev] Re: PEP 654 except* formatting

On 10/4/2021 5:47 PM, Antoine Pitrou wrote: On Mon, 4 Oct 2021 12:18:35 -0400 Calvin Spealman wrote: On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum wrote: The question was about which style to *recommend* (a la PEP-8). I think the very fact that it can't (or is difficult) be

[Python-Dev] Re: PEP 654 except* formatting

On Mon, Oct 4, 2021 at 12:48 PM Antoine Pitrou wrote: > On Mon, 4 Oct 2021 12:18:35 -0400 > Calvin Spealman wrote: > > On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum > wrote: > > > > > The question was about which style to *recommend* (a la PEP-8). > > > > > > > I think the very fact that it

[Python-Dev] Re: PEP 654 except* formatting

On 10/3/2021 10:23 PM, Guido van Rossum wrote: On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble wrote: Therefore my vote is for requiring `except* E` and keeping `except *E` as a SyntaxError. You can't do that with our current lexer+parser. Seems like a good reason to promote  

[Python-Dev] Re: PEP 654 except* formatting

On Mon, Oct 04, 2021 at 09:03:54AM -0700, Guido van Rossum wrote: > The question was about which style to *recommend* (a la PEP-8). Quote: "At the moment * is a separate token so both are allowed, but we could change that (e.g., make except* a token)" If that is mistaken, that's fine, no harm

[Python-Dev] Re: PEP 654 except* formatting

On Mon, 4 Oct 2021 12:18:35 -0400 Calvin Spealman wrote: > On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum wrote: > > > The question was about which style to *recommend* (a la PEP-8). > > > > I think the very fact that it can't (or is difficult) be enforced, How so? If style checkers are

[Python-Dev] Re: PEP 654 except* formatting

On 2021-10-04 16:02, Jonathan Goble wrote: On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum > wrote: On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble mailto:jcgob...@gmail.com>> wrote: Therefore my vote is for requiring `except* E` and keeping `except

[Python-Dev] Re: PEP 654 except* formatting

On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum wrote: > The question was about which style to *recommend* (a la PEP-8). > I think the very fact that it can't (or is difficult) be enforced, and so in the wild we'll likely see variations that could lead to confusion, is enough reason to find an

[Python-Dev] Re: PEP 654 except* formatting

The question was about which style to *recommend* (a la PEP-8). On Mon, Oct 4, 2021 at 8:03 AM Jonathan Goble wrote: > On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum wrote: > >> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble wrote: >> >>> Therefore my vote is for requiring `except* E` and

[Python-Dev] Re: PEP 654 except* formatting

On 2021-10-04 07:12, Greg Ewing wrote: On 4/10/21 6:23 pm, Guido van Rossum wrote: On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > wrote: Therefore my vote is for requiring `except* E` and keeping `except *E` as a SyntaxError. You can't do that with our

[Python-Dev] Re: PEP 654 except* formatting

On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum wrote: > On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble wrote: > >> Therefore my vote is for requiring `except* E` and keeping `except *E` as >> a SyntaxError. >> > > You can't do that with our current lexer+parser. > Then what is the purpose of

[Python-Dev] Re: PEP 654 except* formatting

Another +1 for `except group` from me. On 04/10/2021 2:57 pm, Ammar Askar wrote: Throwing in another +1 for `except group`. It's explicit, doesn't introduce new punctuation and avoids confusion with unpacking. Regards, Ammar On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou

[Python-Dev] Re: PEP 654 except* formatting

To stay consistent with PEP 8, exception groups should use 4 spaces. Victor On Sun, Oct 3, 2021 at 5:54 PM Irit Katriel via Python-Dev wrote: > > > We wonder if people have a view on which of the following is clearer/better: > > 1. except *E as e: // except *(E1, E2) as e: > 2. except* E as

[Python-Dev] Re: PEP 654 except* formatting

> On 4 Oct 2021, at 15:00, Calvin Spealman wrote: > > It is difficult to understand why any special syntax is needed at all. > ExceptionGroup is still an exception class like any other, isn't it? Why > wouldn't the existing syntax suffice? This is covered at length in the PEP. Those sections

[Python-Dev] Re: PEP 654 except* formatting

Throwing in another +1 for `except group`. It's explicit, doesn't introduce new punctuation and avoids confusion with unpacking. Regards, Ammar On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou wrote: > On Sun, 3 Oct 2021 19:42:29 +0200 > Łukasz Langa wrote: > > > > -1 > > > > If I could read the

[Python-Dev] Re: PEP 654 except* formatting

On Sun, Oct 3, 2021 at 11:48 AM Irit Katriel via Python-Dev < python-dev@python.org> wrote: > > We wonder if people have a view on which of the following is > clearer/better: > > 1. except *E as e: // except *(E1, E2) as e: > 2. except* E as e: // except* (E1, E2) as e: > > (The difference is

[Python-Dev] Re: PEP 654 except* formatting

I'm confused, if you can't do that then what is Irit asking? I thought that: > At the moment * is a separate token so both are allowed, but we could change that (e.g., make except* a token), and in any case we need to settle on a convention that we use in documentation, etc. Meant exactly that

[Python-Dev] Re: PEP 654 except* formatting

On Sun, 3 Oct 2021 19:42:29 +0200 Łukasz Langa wrote: > > -1 > > If I could read the vertical line as a pipe character, the expression would > read "except or E as e". > But I can't read it that way anyway. Instead, all I see is a lowercase > EXCEPTL. > > My idea is this: > > try: > ...

[Python-Dev] Re: PEP 654 except* formatting

On Mon, 4 Oct 2021 at 07:16, Greg Ewing wrote: > > On 4/10/21 6:23 pm, Guido van Rossum wrote: > > On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > > wrote: > > > > Therefore my vote is for requiring `except* E` and keeping `except > > *E` as a SyntaxError. > >

[Python-Dev] Re: PEP 654 except* formatting

On 4/10/21 6:23 pm, Guido van Rossum wrote: On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > wrote: Therefore my vote is for requiring `except* E` and keeping `except *E` as a SyntaxError. You can't do that with our current lexer+parser. I don't think it

[Python-Dev] Re: PEP 654 except* formatting

On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble wrote: > Therefore my vote is for requiring `except* E` and keeping `except *E` as > a SyntaxError. > You can't do that with our current lexer+parser. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)*

[Python-Dev] Re: PEP 654 except* formatting

On Sun, Oct 3, 2021 at 11:40 PM Steven D'Aprano wrote: > On Sun, Oct 03, 2021 at 11:34:55AM -0700, Guido van Rossum wrote: > > > I also think that the bar should be pretty high before we reopen the > > *syntax* -- the PEP was approved without anyone (neither the SC, nor > > Nathaniel, nor anyone

[Python-Dev] Re: PEP 654 except* formatting

On Sun, Oct 03, 2021 at 11:34:55AM -0700, Guido van Rossum wrote: > I also think that the bar should be pretty high before we reopen the > *syntax* -- the PEP was approved without anyone (neither the SC, nor > Nathaniel, nor anyone else) providing any feedback on the use of 'except > *'. So I

[Python-Dev] Re: PEP 654 except* formatting

On Oct 3, 2021, at 10:42, Łukasz Langa wrote: > > My idea is this: > > try: >... > except group E as e: >... > except group E1, T2 as e: >... > > Should be doable given the magical match-case contextual keywords precedent. > This looks nice and is explicit, since you will always

[Python-Dev] Re: PEP 654 except* formatting

On Sun, Oct 3, 2021 at 10:47 AM Łukasz Langa wrote: > > I know it's a bit late for bikeshedding this thing so if we want to be > conservative and stick to the current syntactical options already defined > in PEP 654, I'm voting Option 2 (given the awkwardness of the *(E1, E2) > example). > +1

[Python-Dev] Re: PEP 654 except* formatting

> On 3 Oct 2021, at 20:11, MRAB wrote: > > On 2021-10-03 18:50, Brandt Bucher wrote: >> Łukasz Langa wrote: >>> My idea is this: >>> try: >>>... >>> except group E as e: >>>... >>> except group E1, T2 as e: >>>... >>> Should be doable given the magical match-case contextual keywords

[Python-Dev] Re: PEP 654 except* formatting

On Sun, Oct 3, 2021 at 11:28 AM Irit Katriel via Python-Dev < python-dev@python.org> wrote: > We can drop except. Say: > > try: > .. > handle T1: >… > handle T2: >… > > Or ‘catch’, or something else. > We're going around in circles. We considered 'catch' early on, but decided against

[Python-Dev] Re: PEP 654 except* formatting

We can drop except. Say: try: .. handle T1: … handle T2: … Or ‘catch’, or something else. > On 3 Oct 2021, at 19:12, MRAB wrote: > > On 2021-10-03 18:50, Brandt Bucher wrote: >> Łukasz Langa wrote: >>> My idea is this: >>> try: >>>... >>> except group E as e: >>>... >>>

[Python-Dev] Re: PEP 654 except* formatting

On 2021-10-03 18:50, Brandt Bucher wrote: Łukasz Langa wrote: My idea is this: try: ... except group E as e: ... except group E1, T2 as e: ... Should be doable given the magical match-case contextual keywords precedent. This looks nice and is explicit, since you will always get an

[Python-Dev] Re: PEP 654 except* formatting

Łukasz Langa wrote: > My idea is this: > try: > ... > except group E as e: > ... > except group E1, T2 as e: > ... > Should be doable given the magical match-case contextual keywords precedent. > This looks nice and is explicit, since you will always get an ExceptionGroup > instance

[Python-Dev] Re: PEP 654 except* formatting

Irit Katriel wrote: > It is also not too late to opt for a completely different syntax if a better > one is suggested. Honestly, I’ve never been a fan of the PEP’s proposed star syntax. If we’re okay adding a soft keyword, though, something like “except each” could help communicate the meaning

[Python-Dev] Re: PEP 654 except* formatting

> On 3 Oct 2021, at 18:37, Steven D'Aprano wrote: > > On Sun, Oct 03, 2021 at 04:47:57PM +0100, Irit Katriel via Python-Dev wrote: >> We wonder if people have a view on which of the following is clearer/better: >> >> 1. except *E as e: // except *(E1, E2) as e: > > That looks like you're

[Python-Dev] Re: PEP 654 except* formatting

On Sun, Oct 03, 2021 at 04:47:57PM +0100, Irit Katriel via Python-Dev wrote: > We wonder if people have a view on which of the following is clearer/better: > > 1. except *E as e: // except *(E1, E2) as e: That looks like you're unpacking the tuple (E1, E2), and that's just misleading and

[Python-Dev] Re: PEP 654 except* formatting

except* looks like the exception statement has a footnote, which isn't wrong. *(E1, E2) looks like they are being unpacked, which is wrong. -jJ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to

[Python-Dev] Re: PEP 654 except* formatting

On Sun, 3 Oct 2021 at 16:55, Irit Katriel via Python-Dev wrote: > > We wonder if people have a view on which of the following is clearer/better: > > 1. except *E as e: // except *(E1, E2) as e: > 2. except* E as e: // except* (E1, E2) as e: > > (The difference is in the whitespace around the

[Python-Dev] Re: PEP 654 except* formatting

We’ll, typically you don’t explicitly mention ExceptionGroup — it’s implied by the ‘except*’ syntax. Introducing match semantics probably wouldn’t open up new functionality, you can already write ‘except (E1, E2):’. On Sun, Oct 3, 2021 at 09:00 Thomas Grainger wrote: > What about `except case

[Python-Dev] Re: PEP 654 except* formatting

What about `except case ExceptionGroup[E1 | E2]:`? and use match semantics? On Sun, 3 Oct 2021, 16:50 Irit Katriel via Python-Dev, < python-dev@python.org> wrote: > > We wonder if people have a view on which of the following is > clearer/better: > > 1. except *E as e: // except *(E1, E2) as e: