[Python-Dev] PEP 654 except* formatting

[Irit Katriel via Python-Dev]

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

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.

It is also not too late to opt for a completely different syntax if a better one is suggested. 

[Thomas Grainger]

What about `except case ExceptionGroup[E1 | E2]:`? and use match semantics?

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Guido van Rossum]

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):’.

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/XNZNX2M2PQ24VEH5GWCGVFS5EY6XMRAX/

Code of Conduct: http://python.org/psf/codeofconduct/

--

--Guido (mobile)

[Paul Moore]

On Sun, 3 Oct 2021 at 16:55, Irit Katriel via Python-Dev
<pytho...@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 in the whitespace around the *).

I prefer (1). I never liked C declarations where the * was attached to
the type rather than the variable, and I have the same dislike here.

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

Having said the above, it's a matter of taste/preference, so I think
that allowing both is the correct thing to do.

> It is also not too late to opt for a completely different syntax if a better one is suggested.

Let's stick with "except *". It doesn't seem productive to have
another round of bikeshedding at this point, unless there's a really
compelling technical reason (i.e., something significantly more than
mere bikeshedding).

Paul

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/BZ55ZMS5S5E7KPNP7AR7N2BSA35KVKF3/

[Jim J. Jewett]

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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/7IKS3YFPFT5JO7QBJGNPMM33XUYKK7CK/

[Steven D'Aprano]

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

> 2. except* E as e: // except* (E1, E2) as e:

That looks like it is the "except" keyword which is special, not the
tuple. If we're going to have yet another meaning for star
(multiplication, replication, unpacking, powers, wildcard imports...)
then I vote for 2.

But Thomas Grainger's comment about match semantics got me thinking. I
think his suggestion is a bit too verbose, but how do people feel about
borrowing the vertical line and using it like this:

except| E as e:
except| (E1, E2) as e:

Again, it's attached to the except keyword, to indicate that it's the
keyword which is special, not a unary prefix operator on the E.

The vertical line is suggestive of grouping something with a box around
it:

+-----------------+
| group of things |
+-----------------+

and of the lines used in tracebacks shown in the PEP. So the output
helps remind you of the syntax.



--
Steve

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/EA7E3EGQ6WB5O3ITPTN53C4CMFHDLBFK/

[Łukasz Langa]

> On 3 Oct 2021, at 18:37, Steven D'Aprano <st...@pearwood.info> 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 unpacking the tuple (E1, E2), and that's just
> misleading and wrong.

Interestingly, IIRC this was the original intention: `except *E as e` means you're unpacking E from some group.
I agree this is a somewhat convoluted analogy and it breaks down in the presence of a tuple of exception names.

>> 2. except* E as e: // except* (E1, E2) as e:
>

> But Thomas Grainger's comment about match semantics got me thinking.

Uh oh ;-)

> I think his suggestion is a bit too verbose, but how do people feel about
> borrowing the vertical line and using it like this:
>
> except| E as e:
> except| (E1, E2) as e:

-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:
...
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 under `e`. But 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).


- Ł

[Brandt Bucher]

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 of the blocks a bit more explicitly. I’m pretty sure that grammar would be unambiguous in all cases.

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/44TWMI3PV3TKRL6ZJ4YU3GMQ6W43EHU5/

[Brandt Bucher]

Ł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 under `e`.

Heh, we crossed posts with the soft keywords. I like your idea (“except group”) better than mine (“except each”).

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/4FPTSD6VAIJD2WSP63KQUOQLDAOI3EWR/

[MRAB]

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 ExceptionGroup instance under `e`.
>
> Heh, we crossed posts with the soft keywords. I like your idea (“except group”) better than mine (“except each”).

> If we want to use an existing keyword instead of a soft keyword, how
about "except in E as e:".

The disadvantage, as I see it, from a linguistic point of view, is that
"except in" could be read as "excluding", but, then, so could "except
each" ("excluding each of these") and "except group" ("excluding this
group").

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/FUTYE36MLFAWU72KTHDEQY5JFDA2PQ4G/

[Irit Katriel via Python-Dev]

We can drop except. Say:

try:
..
handle T1:
…
handle T2:
…

Or ‘catch’, or something else.


> On 3 Oct 2021, at 19:12, MRAB <pyt...@mrabarnett.plus.com> wrote:

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/K3I7552LB6O5XS3KWLC2C2U5XME43HQ5/

[Guido van Rossum]

On Sun, Oct 3, 2021 at 11:28 AM Irit Katriel via Python-Dev <pytho...@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 it since, comparing 'except E' and 'catch E', there would be no good way to tell which is the recommended one (and the same would apply to another single keyword like 'handle'). At least with 'except*', it's easy to remember that this is a modified version of 'except', so it's probably meant for a special case.

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 think it's a bit late to be bikeshedding the syntax. This thread was meant to solicit feedback on how to *format* it: does the space go before or after the '*'.

--

--Guido van Rossum (python.org/~guido)

Pronouns: he/him (why is my pronoun here?)

[Łukasz Langa]

> On 3 Oct 2021, at 20:11, MRAB <pyt...@mrabarnett.plus.com> 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 precedent. This looks nice and is explicit, since you will always get an ExceptionGroup instance under `e`.
>> Heh, we crossed posts with the soft keywords. I like your idea (“except group”) better than mine (“except each”).
>> If we want to use an existing keyword instead of a soft keyword, how
> about "except in E as e:".
>
> The disadvantage, as I see it, from a linguistic point of view, is that "except in" could be read as "excluding", but, then, so could "except each" ("excluding each of these") and "except group" ("excluding this group").

If you're thinking that, then doesn't "except KeyError" mean "everything except for KeyErrors"? I don't see the problem.

- Ł

[Gregory P. Smith]

On Sun, Oct 3, 2021 at 10:47 AM Łukasz Langa <luk...@langa.pl> 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 on the `except* E` Option 2 syntax. It better conveys its uniqueness and non-relation to other meanings of *.

Someone mentioned allowing both and letting people decide.  Whatever is chosen, please not that.  There should be only one way to write this.  That avoids style arguments when no auto-formatter is involved.

-gps

- Ł

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/T7QZJ575RFNYZ5KMYD66YMR2ZLNDVF56/

[Barry Warsaw]

On Oct 3, 2021, at 10:42, Łukasz Langa <luk...@langa.pl> 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 under `e`. But 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).

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 I would be in favor of that, or something like it.

We could of course bike shed on the syntax forever. The PSC did vote to accept the PEP but we left room for changes while during the 3.11 cycle.

-Barry

[Steven D'Aprano]

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 think it's a bit late to be bikeshedding the syntax. This thread
> was meant to solicit feedback on how to *format* it: does the space go
> before or after the '*'.

`except* E`, otherwise it looks like unpacking E.

Done! Bikeshedding is over! *wink*

All joking aside, my preference is to put the star on the except, not
the exceptions. I don't think I have anything more to say that hasn't
already been said, so I'll bow out now.

--
Steve

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/5TRLGMHCOTEF3MMR6GR35TLG6TPG63VJ/

[Jonathan Goble]

On Sun, Oct 3, 2021 at 11:40 PM Steven D'Aprano <st...@pearwood.info> 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 else) providing any feedback on the use of 'except
> *'. So I think it's a bit late to be bikeshedding the syntax. This thread
> was meant to solicit feedback on how to *format* it: does the space go
> before or after the '*'.

`except* E`, otherwise it looks like unpacking E.

I think it's worth noting that the following is already legal:

Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exceptions = (ValueError, TypeError)
>>> try:
...   raise TypeError
... except exceptions:
...   print("caught")
...
caught

Indeed, when I first learned that you could do this (a few years ago IIRC), my first thought was to unpack the "exceptions" tuple with a star. It wasn't until I tried that and got a SyntaxError that I tried it the way shown here and it worked.

Allowing `except *E` for this new feature would take that helpful-to-a-beginner SyntaxError and turn it into a subtle and unhelpful bug.

Therefore my vote is for requiring `except* E` and keeping `except *E` as a SyntaxError.

[Guido van Rossum]

On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble <jcgo...@gmail.com> 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.

[Greg Ewing]

On 4/10/21 6:23 pm, Guido van Rossum wrote:
> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble <jcgo...@gmail.com
> <mailto:jcgo...@gmail.com>> 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 would be desirable in any case. The separation of
tokens into alphanumeric and non-alphanumeric is deeply embedded in
every Python programmer's brain by now, and we shouldn't mess with
it.

--
Greg

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/XQXJEGYAWBTAUQI3BEIXDZO4SERAJYWF/

[Paul Moore]

On Mon, 4 Oct 2021 at 07:16, Greg Ewing <greg....@canterbury.ac.nz> wrote:
>
> On 4/10/21 6:23 pm, Guido van Rossum wrote:
> > On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble <jcgo...@gmail.com
> > <mailto:jcgo...@gmail.com>> 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 would be desirable in any case. The separation of
> tokens into alphanumeric and non-alphanumeric is deeply embedded in
> every Python programmer's brain by now, and we shouldn't mess with
> it.

Agreed. Having "except*" be a single token, distinguished from the
pair of tokens "except" "*" only by the presence of whitespace, would
be extremely confusing.

And yes, I am aware that 3.as_integer_ratio() and 3.
as_integer_ratio() are syntax errors, whereas 3 .as_integer_ratio()
and 3 . as_integer_ratio() are valid. IMO, that's *also* very
confusing, and serves as a warning to not do that again, and not as an
example of how it's OK and we can do more of that...

Paul

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/IKWKS6VYWFQ4XEXJ4XFYBLPRPXATKGGL/

[Antoine Pitrou]

On Sun, 3 Oct 2021 19:42:29 +0200
Łukasz Langa <luk...@langa.pl> 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:
> ...
> 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 under `e`.

+1. This is much more helpful to the reader than the cryptic
asterisk.

Regards

Antoine.

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/INK6TSOGGODA4NZ3CI5MOXIAI4Z4CZ53/

[Damian Shaw]

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 was the question being asked.

Damian (he/him)

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/F2JUI7SWTQE6RJ4YYKQHJ233BERZHYWR/

[Calvin Spealman]

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?

 

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/

Code of Conduct: http://python.org/psf/codeofconduct/

--

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin....@redhat.com  M: +1.336.210.5107

TRIED. TESTED. TRUSTED.

[Ammar Askar]

Throwing in another +1 for `except group`. 

It's explicit, doesn't introduce new punctuation and avoids confusion with unpacking.

Regards,

Ammar

[Łukasz Langa]

On 4 Oct 2021, at 15:00, Calvin Spealman <cspe...@redhat.com> 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 specifically address this:

https://www.python.org/dev/peps/pep-0654/#extend-except-to-handle-exception-groups

https://www.python.org/dev/peps/pep-0654/#programming-without-except

- Ł

[Victor Stinner]

To stay consistent with PEP 8, exception groups should use 4 spaces.

Victor

> _______________________________________________
> Python-Dev mailing list -- pytho...@python.org
> To unsubscribe send an email to python-d...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/

> Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/

> Code of Conduct: http://python.org/psf/codeofconduct/

--
Night gathers, and now my watch begins. It shall not end until my death.

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/A2REM55FHTETDZUPRVDWTVSXC273GHZW/

[Mark Shannon]

Another +1 for `except group` from me.

> <mailto:pytho...@python.org>

> To unsubscribe send an email to python-d...@python.org

> <mailto:python-d...@python.org>
> https://mail.python.org/mailman3/lists/python-dev.python.org/

> <https://mail.python.org/mailman3/lists/python-dev.python.org/>
> Message archived at
> https://mail.python.org/archives/list/pytho...@python.org/message/INK6TSOGGODA4NZ3CI5MOXIAI4Z4CZ53/
> <https://mail.python.org/archives/list/pytho...@python.org/message/INK6TSOGGODA4NZ3CI5MOXIAI4Z4CZ53/>
> Code of Conduct: http://python.org/psf/codeofconduct/

> <http://python.org/psf/codeofconduct/>

>
>
> _______________________________________________
> Python-Dev mailing list -- pytho...@python.org
> To unsubscribe send an email to python-d...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/

> Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/4ZUBUDQ4CGXYJAIYKMJMJBGUGGTODECF/

> Code of Conduct: http://python.org/psf/codeofconduct/
>

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/OFSIDJNKCXPXRJJNFDUG3JKNLPJUQGLD/

[Jonathan Goble]

On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum <gu...@python.org> wrote:

On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble <jcgo...@gmail.com> 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 this thread? I understood from the OP that the question was which to allow and which to prohibit. If it's impossible to require either or prohibit either because the lexer/parser can't tell the difference, then it's going to end up as a never-ending style argument just like C pointers, so what are we even discussing? (Other than an entirely different syntax, of course, which now seems like the logical way to go if we can't enforce a single way to do it with the original proposal.)

[MRAB]

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 <jcgo...@gmail.com
>> <mailto:jcgo...@gmail.com>> 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 would be desirable in any case. The separation of
> tokens into alphanumeric and non-alphanumeric is deeply embedded in
> every Python programmer's brain by now, and we shouldn't mess with
> it.
>

It's not just a Python thing.

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/NTAXBGISW5CGLR2CWQ7HN4CCMDNF6OPG/

[Guido van Rossum]

The question was about which style to *recommend* (a la PEP-8).

[MRAB]

> The key phrase is """in any case we need to settle on a convention that
we use in documentation, etc.""".

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/RYJTNZVMNF54XVUIE4MMN6TXS2XRPTXO/

[Calvin Spealman]

On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum <gu...@python.org> 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 alternative syntax.

 

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/DASEBDJ6CK6U4YHRKPJ7CNQQHVWEWOLQ/

Code of Conduct: http://python.org/psf/codeofconduct/

[Steven D'Aprano]

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 done, but those of us who
thought that enforcing one or the other form was on the table didn't
imagine it :-)

--
Steve
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/CODOHGNW7F2AKMVPGLZZCMWLVKOINBIM/

[Antoine Pitrou]

On Mon, 4 Oct 2021 12:18:35 -0400
Calvin Spealman <cspe...@redhat.com> wrote:
> On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum <gu...@python.org> 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 already able to check whitespace around
operators, they should be to check whitespace in this instance as well.

Do you suggest that PEP 8 violations should be detected by the Python
parser itself?

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/ZLU5NYXVRCUM7AEEN55ITUQO43VDY6RE/

[Glenn Linderman]

On 10/3/2021 10:23 PM, Guido van Rossum wrote:

On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble <jcgo...@gmail.com> 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   "except group E"  instead of "except * E", as others have suggested.

[Calvin Spealman]

On Mon, Oct 4, 2021 at 12:48 PM Antoine Pitrou <ant...@python.org> wrote:

On Mon, 4 Oct 2021 12:18:35 -0400
Calvin Spealman <cspe...@redhat.com> wrote:
> On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum <gu...@python.org> 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 already able to check whitespace around
operators, they should be to check whitespace in this instance as well.

Do you suggest that PEP 8 violations should be detected by the Python
parser itself?

1) I was basing the "can't enforce" on Guido's " You can't do that with our current lexer+parser."

2) Of course PEP 8 violations shouldn't be checked by the parser. That's why they're PEP 8 and not syntax rules.

However, this doesn't look like style. This syntax is modifying either the `except` keyword for the exception type
associated with it.

Which does it modify? That the asterisk can be on either side of the whitespace feels very odd, in general but

especially for Python syntax. That's why I'd opt for a variation that is either unambiguously attached to the left or right,

or which is not connected to either, like the very clear `except group E` proposal.

 

_______________________________________________

Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/ZLU5NYXVRCUM7AEEN55ITUQO43VDY6RE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Steve Dower]

On 10/4/2021 5:47 PM, Antoine Pitrou wrote:
> On Mon, 4 Oct 2021 12:18:35 -0400
> Calvin Spealman <cspe...@redhat.com> wrote:
>> On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum <gu...@python.org> 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 already able to check whitespace around
> operators, they should be to check whitespace in this instance as well.
>
> Do you suggest that PEP 8 violations should be detected by the Python
> parser itself?

No, but if it isn't decided by *us*, it'll be decided by whoever
contributes it to Black first.

To me, the "*name" looks most similar to how we write "*args" in a
function definition, so I'd go for that.

We don't currently modify[1] keywords with punctuation, and that's what
"except*" looks like, and "except * E" looks like a binary operator
and/or grit on the screen.

Cheers,
Steve

[1]: Meaning to "give it a different meaning in particular context", not
_literally_ modify in any permanent sense.

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/52KJZMKMFTFHVMS3NXABNFQJRZNLKLX5/

[Rob Cliffe via Python-Dev]

On 04/10/2021 00:57, Barry Warsaw wrote:

On Oct 3, 2021, at 10:42, Łukasz Langa <luk...@langa.pl> 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 I would be in favor of that, or something like it.

Or perhaps `except for` ?

We could of course bike shed on the syntax forever.  The PSC did vote to accept the PEP but we left room for changes while during the 3.11 cycle.

-Barry

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/7KHAN76UA5JRND2M2EMVLKML665KQDTC/

[Terry Reedy]

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 *before*
'except', the pair is recognized as a keyword phrase by IDLE's syntax
highlighter without any change. ('except\s*group' would take care of
variable spacing)


--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/EYS6Q53UN2KDBH2VM4KA7DVRL76KJYVX/

[Steven D'Aprano]

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

See for example Jonathon Goble's experience here:

https://mail.python.org/archives/list/pytho...@python.org/message/2TBZZSMZXNYFJNPLIESFNFDNDX5K6A5X/

> We don't currently modify[1] keywords with punctuation,

Star imports are a possible exception. But there we have no way of
confusing the meaning.

> and that's what
> "except*" looks like, and "except * E" looks like a binary operator
> and/or grit on the screen.

When I saw the `except*` syntax first suggested, I was a little
surprised because it did seem rather unusual for Python. But I grew up
with FORTH where function names contain punctuation all the time, so I
didn't think too much of it. I expected that the keyword literally would
be `except*` and nothing but `except*`.

If I had realised that the star would be free to wander around and that
the syntax actually was r"except[ \t]*\*[ \t]*", I would have said
something much earlier :-(

--
Steve

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/GZOOLRO7RYWNKA3QWGNGXGXVV3KNNR4Q/

[Patrick Reader]

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 any number of dynamically chosen exception types.

[Patrick Reader]

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, <pytho...@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 in the whitespace around the *).

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.

It is also not too late to opt for a completely different syntax if a better one is suggested.

I don't think X[Y | Z] is close to any syntax match currently allows.

But... I have long thought that the interpreter's exception matching abilities were underused by the language. Maybe this is an opportunity for something else interesting, in general?

The problem being, besides the general extra complexity, that the match statement's variable capture semantics are different to the `as name` syntax already used by the except statement.

[Patrick Reader]

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 arbitrary expression there - it looks like it will match any number of dynamically chosen exception types.

(that could be a useful feature actually (so maybe the * syntax should be reserved??), but that's another discussion)

[Calvin Spealman]

But it only looks like splatting because you changed it from `(E1, E2)` to `(e1, e2)` where Title Case names will look like a matched type and lower case names will look like destination names. So, given these will be class names and 99.9% Title Case, Option 1 does not really fail under your suggested confusion here.

 

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/RGIAE2HMYQLPXWH5O5TNBNRXDQQ4UKAK/

Code of Conduct: http://python.org/psf/codeofconduct/

[sascha.schlemmer--- via Python-Dev]

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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/PFYQC7XMYFAGOPU5C2YVMND2BQSIJPRC/

[Greg Ewing]

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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/O7V4G4DWEOXNWZB6MP4PKOXV46XKVT67/

[Steven D'Aprano]

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, 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 any
> > number of dynamically chosen exception types.
> >
> But it only looks like splatting because you changed it from `(E1, E2)` to
> `(e1, e2)` where Title Case names will look like a matched type and lower
> case names will look like destination names. So, given these will be class
> names and 99.9% Title Case, Option 1 does not really fail under your
> suggested confusion here.

It's the asterisk `*`, not the case of the names, that makes it look
like sequence unpacking.

Sequence unpacking works on sequences of types or other names that start
with capital letters. There is no difference between unpacking a tuple
of classes with a capital letter and a tuple of classes with names that
start with lower case letters:

a, b, c = *(ValueError, TypeError, Exception)
a, b, c = *(int, float, str)

Shockingly, we can even use mixed case and unusual naming conventions!

obj, Module = (None, sys)

*wink*

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/DTUIIVXGKA2MEBK6K3ZUOVHTLFRJC4HB/

[Barry Warsaw]

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

[Barry Warsaw]

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 <pytho...@python.org> wrote:
>

[MRAB]

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 mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/YHTK2JCUX4KZ6EDNYLAUEHXD2XNZTUDT/

[Ethan Furman]

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

--
~Ethan~

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/5E5OJAE6BZPANHII5QTYZ6KRGUPCS6WX/

[Larry Hastings]

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 "await" in 3.5, would lead to ambiguity:

group = KeyboardInterrupt

try:
    while True:
        print("thou can only defeat me with Ctrl-C")
except group as error:
    print("lo, thou hast defeated me")

/arry

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/SZNDJPKT7WNWJHG4UDJ6D3BU6IN5ZXZO/

[Łukasz Langa]

On 6 Oct 2021, at 12:06, Larry Hastings <la...@hastings.org> 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. I maintain this will be entirely backwards compatible.

Even making it a soft keyword, a la "await" in 3.5, would lead to ambiguity: 

group = KeyboardInterrupt

try:
    while True:
        print("thou can only defeat me with Ctrl-C")
except group as error:
    print("lo, thou hast defeated me")

Two things:

1. This is a convoluted example, I bet $100 you won't find such an `except group` statement in any code predating my e-mail 🤠 Sure, sometimes (very rarely) it's useful to gather exceptions in a variable. But I'm pretty sure `group` won't be the name chosen for it.

2. While non-obvious, the example is not ambiguous. There can only be one parsing rule fitting this:

'except' expression 'as' NAME ':'

Note how this is different from:

'except' 'group' expression 'as' NAME ':'

There could be confusion if except-star, whatever its name is going to be, supported an empty "catch all" variant like `except:`. Thankfully, this is explicitly listed as a no-go in PEP 654. So `except group:` remains unambiguous. 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".

- Ł

[Petr Viktorin]

On 06. 10. 21 15:34, Łukasz Langa wrote:
>
>> On 6 Oct 2021, at 12:06, Larry Hastings <la...@hastings.org

What about this:

group = (KeyboardInterrupt, MemoryError)
other_group = (KeyError, IndexError)

try:
...
except group + other_group as error:

...
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/KH7T6VDRYENBLLFNY7CAXFEVH4IILXZ7/

[Łukasz Langa]

> On 6 Oct 2021, at 16:01, Petr Viktorin <enc...@gmail.com> 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 statement 👨🏻‍🔬

Joking aside, since we allow any expression after 'except' 'group' then this is indeed ambiguous. In theory! In practice, however, PEG is satisfied with the first rule that matches entirely, so this is a matter of choosing correct precedence. In this case, it seems it would make sense for "old-style" except to come first because your (convoluted! 🤠) example is potentially useful, whereas "except +TimeoutError:" is pure nonsense.

I will prototype a PR for this just so we can play with it.

- Ł

[Brandt Bucher]

Ł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: …
except (KeyError, IndexError) group as e: …
except some + expression group as e: …

And edge-cases like this still work normally:

except some + group as e: …

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/TW5I4Z3XKCSZC6IRXHNFVPZVLHEKI7O3/

[Yury Selivanov]

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 of E into a group) in the same grammar worries me.

1a. It can be especially confusing if someone has a local/global variable called `group`.

1b. Or, for example, if a user forgets to type `E` and leaves just `except group` it would fallback to the regular try..except behavior. And it would be a runtime error ("group" is undefined).

1c. This will be all even more complicated because syntax highlighters in IDEs and on sites like GitHub will likely just always highlight `except group` as a pair of keywords (even in `except group:` variant).

2. I'm not sure I like the "sound" of it. 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).

3. This is a niche feature. People who use async/await will get used to `except*` in no time. `except*` is also about unpacking in some metaphysical sense (looks similar enough to `*args` in function signatures to me) so I think it reads just fine.

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.

Yury

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/SZNDJPKT7WNWJHG4UDJ6D3BU6IN5ZXZO/

Code of Conduct: http://python.org/psf/codeofconduct/

--

         Yury

[Larry Hastings]

On 10/6/21 2:34 PM, Łukasz Langa wrote:

On 6 Oct 2021, at 12:06, Larry Hastings <la...@hastings.org> 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. I maintain this will be entirely backwards compatible.

My claim is that making "group" a hard-coded keyword, visible at all times, and thus no longer permitting use of "group" as an identifier, would play havoc with a lot of existing code.  I don't think it's an extraordinary claim to say that "group" is a reasonably popular identifier.  For example, I offer the 1,117 uses of the word "group" in the Python 3.10.0 Lib/ directory tree.  (I admit I didn't review them all to see which ones were actual identifiers, and which ones were in strings or documentation.)

If the proposal is to add it as some "it's only a keyword in this context" magic thing, a la how "async"/"await" were "soft keywords" in 3.5, and if we otherwise would permit the word "group" to be used as an identifier in perpetuity--okay, it won't cause this problem.

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

I concede I don't completely understand PEP 654 yet, much less the counter-proposals flying around right now.  But it does seem like "except group" has the potential to be ambiguous, given that "group" is a reasonably popular identifier.

/arry

[Antoine Pitrou]

On Wed, 6 Oct 2021 09:05:57 -0700
Yury Selivanov <yseliv...@gmail.com> 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"?

Regards

Antoine.

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/MO3XHOBKG2USFV5VEKZDZ3GBV7V2WJFO/

[Brandt Bucher]

Ł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 alternative (putting “group” after the expression).

Brandt

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/BUK2YFLH4TPIRTPG5JAYKNEWOBJTHC2B/

[Łukasz Langa]

Sure, that I agree with, it's a very popular name.

- Ł

[Łukasz Langa]

> On 6 Oct 2021, at 18:14, Brandt Bucher <brandt...@gmail.com> 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: …
> except group(E1, E2) as e: …

Ding ding, we have a winner. This single-handedly kills the "except group" syntax proposal.

> See my other message for an alternative (putting “group” after the expression).

It's interesting but at this point not so clearly better than except* to my eyes. Unless everybody else loves it, I don't think we'll go there.

- Ł

[Barry Warsaw]

That might be exceptable.

-Barry

[Łukasz Langa]

On 6 Oct 2021, at 18:05, Yury Selivanov <yseliv...@gmail.com> 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

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 of E into a group) in the same grammar worries me.

1a. It can be especially confusing if someone has a local/global variable called `group`.

This is a valid point, also raised by Pablo over WhatsApp (which happens to work today!). The particular hairy example has to do with your next point so let's go there first...

1b. Or, for example, if a user forgets to type `E` and leaves just `except group` it would fallback to the regular try..except behavior. And it would be a runtime error ("group" is undefined).

Right. Worse yet, this wouldn't be a runtime error UNLESS user code raises an exception within that try: block. Otherwise Python would happily take the unbound name and run with it:

>>> try:

...   ...

... except group:

...   ...

...

Ellipsis

When you raise:

>>> try:

...   1/0

... except group:

...   ...

...

Traceback (most recent call last):

  File "<stdin>", line 2, in <module>

ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

  File "<stdin>", line 3, in <module>

NameError: name 'group' is not defined

This is pretty confusing and in my eyes disqualifies the "except group" proposal. Pablo also claims it would be very hard to generate good error messages due to this and I can see why. My initial idea here was to modify this received `NameError` just like we do in other cases with the new "Did you mean" helper:

>>> arg = 1

>>> ar

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

NameError: name 'ar' is not defined. Did you mean: 'arg'?

>>> def f():

...   ar

...

>>> f()

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "<stdin>", line 2, in f

NameError: name 'ar' is not defined. Did you mean: 'arg'?

We could potentially do something similar to generate better error messages for "except group" confusion, right? Only we can't if `group` happens to be bound as a name in a reachable scope which Larry points out is a popular name. In this scenario any syntax errors would end up with terribly confusing TypeErrors or AttributeErrors and so on. This is unacceptable.

1c. This will be all even more complicated because syntax highlighters in IDEs and on sites like GitHub will likely just always highlight `except group` as a pair of keywords (even in `except group:` variant).

This would a minor annoyance but definitely true.

2. I'm not sure I like the "sound" of it. 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).

That I disagree with. "except KeyError" reads like "except if there's a KeyError". "except group KeyError" reads like "except if there's a group of KeyErrors". And if you said, "except group KeyError as eg", an ExceptionGroup with KeyErrors would be exactly what you're getting under `eg`.

3. This is a niche feature. People who use async/await will get used to `except*` in no time. `except*` is also about unpacking in some metaphysical sense (looks similar enough to `*args` in function signatures to me) so I think it reads just fine.

Agreed. Except-star will be fine, too.

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.

Making `group` a proper keyword is a no go. With Brandt's arguments, the entire idea is a no go. It's a bummer but I have to agree with the concerns raised. 

- Ł

[Steve Dower]

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 keyword. That would be disastrous (e.g. re.Match.group()
becomes unusable).

A soft keyword, punctuation, or magic builtin are the only possibilities
here.

"except all ..." is viable, since it's already a builtin that isn't
useful as "except all:". But if that's the case, "except ExceptionGroup"
is equally viable (with perhaps "except ExceptionGroup[Specific, Type]"
for filtering?)

I'm not going to argue against "except *", as that's already been
accepted. But any alternative needs to:
* break the same amount of existing code (i.e. none)
* be equally/more readable and discoverable

Since "except *" breaks *no* existing code, that's a pretty easy thing
to check for in any alternative. But since "*" here has no precedent (as
we've seen in this discussion), virtually any alternative is going to be
more readable.

So enjoy bikeshedding, everyone :) Please don't break any of our code.

Cheers,
Steve

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/YOTXVPFABO4YKQ7TSEA3NMGNF47MBH5T/

[Thomas Grainger]

How about
```
try:
...
exceptgroup E1, E2:
...
``

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/QY2I5EWUZZZWPCLS7YFFWR7RDRNGTCY7/

[Calvin Spealman]

On Wed, Oct 6, 2021 at 12:01 PM Brandt Bucher <brandt...@gmail.com> 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 points for reading more clearly:

except MemoryError group as e: …
except (KeyError, IndexError) group as e: …
except some + expression group as e: …

I like the clarity of this a lot. +100

 

And edge-cases like this still work normally:

except some + group as e: …
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/TW5I4Z3XKCSZC6IRXHNFVPZVLHEKI7O3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Pablo Galindo Salgado]

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 invalid code, with some generality

(like "starts with this token and then anything can follow until this other token"). Soft keywords also make

highlighters' life more complicated as it has already been discussed.

And just to be clear: I am not saying they are bad, just that they are not free of cost.

[Guido van Rossum]

On Wed, Oct 6, 2021 at 9:01 AM Brandt Bucher <brandt...@gmail.com> 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 group as e: …

Argh. This would be very easy to overlook. As the senior author of PEP 654 I am going to go with "except*". Since it was shown that "except group" has ambiguous edge cases the proposals have gotten worse, which to me is a good sign that we need to stop.

--

--Guido van Rossum (python.org/~guido)

Pronouns: he/him (why is my pronoun here?)

[Barry Scott]

On 6 Oct 2021, at 18:48, Guido van Rossum <gu...@python.org> wrote:

On Wed, Oct 6, 2021 at 9:01 AM Brandt Bucher <brandt...@gmail.com> 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 group as e: …

Argh. This would be very easy to overlook. As the senior author of PEP 654 I am going to go with "except*". Since it was shown that "except group" has ambiguous edge cases the proposals have gotten worse, which to me is a good sign that we need to stop.

With async it goes *before* def, for, with.

Can you put the group before the except in the same style?

try:

stuff...

group except :

handler...

Barry

--

--Guido van Rossum (python.org/~guido)

Pronouns: he/him (why is my pronoun here?)

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/RRHP6VRI5PUMRSIXKFQVR2E6L523NUVC/

[Jim J. Jewett]

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 exception, so any current meaning would be, at the least, a dodgy renaming of a built-in to something unrelated -- in which case a reader *should* already be suspicious.

-jJ

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/GRVMPGZFNE67GE25SQCRCQWZQFZMA7PX/

[Patrick Reader]

try:

    ...

except group (KeyError, ZeroDivisionError) as error:

    ...


With the precedence you suggest, now group(...) becomes a function call.

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/LW4RJO5DTBO7CEYBTT2E7UTHCL6SCXK7/

[Patrick Reader]

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 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 "await" in 3.5, would lead to ambiguity:
>
> group = KeyboardInterrupt
>
> try:
>     while True:
>         print("thou can only defeat me with Ctrl-C")
> except group as error:
>     print("lo, thou hast defeated me")
>
>

> //arry/

>
> On 10/6/21 2:12 AM, 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.
>>
>> -Barry
>>

>> wrote:
>>
>> 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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/5N4FDYAW5AB2AXMGM6CBRSN6PK3IWMRD/

[Patrick Reader]

On 06/10/2021 17:35, Łukasz Langa wrote:

On 6 Oct 2021, at 18:05, Yury Selivanov <yseliv...@gmail.com> wrote:

[...]

Now a moot point, but this could be a SyntaxWarning.

[Steven D'Aprano]

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...@python.org/message/6KQUQBKFGJSGDNXFZBSM5OXD2ISLIQTT/

Rob's idea is to use "except for ..." with exception groups, instead of
a new keyword or symbol.


--
Steve

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/62ZX4T226BCRQE7ZNJPSJNNBAP735K2J/