[Python-Dev] PEP 654 except* formatting

74 views
Skip to first unread message

Irit Katriel via Python-Dev

unread,
Oct 3, 2021, 11:48:33 AM10/3/21
to 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

unread,
Oct 3, 2021, 11:59:46 AM10/3/21
to Irit Katriel, python-dev
What about `except case ExceptionGroup[E1 | E2]:`? and use match semantics?

Guido van Rossum

unread,
Oct 3, 2021, 12:29:34 PM10/3/21
to Thomas Grainger, Irit Katriel, python-dev
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):’.

--
--Guido (mobile)

Paul Moore

unread,
Oct 3, 2021, 12:37:33 PM10/3/21
to Irit Katriel, python-dev
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

unread,
Oct 3, 2021, 12:40:43 PM10/3/21
to pytho...@python.org
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

unread,
Oct 3, 2021, 12:42:01 PM10/3/21
to pytho...@python.org
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

unread,
Oct 3, 2021, 1:47:29 PM10/3/21
to Steven D'Aprano, pytho...@python.org

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


- Ł
signature.asc

Brandt Bucher

unread,
Oct 3, 2021, 1:47:39 PM10/3/21
to pytho...@python.org
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

unread,
Oct 3, 2021, 1:53:40 PM10/3/21
to pytho...@python.org
Ł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

unread,
Oct 3, 2021, 2:14:07 PM10/3/21
to pytho...@python.org
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

unread,
Oct 3, 2021, 2:27:48 PM10/3/21
to MRAB, pytho...@python.org
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

unread,
Oct 3, 2021, 2:39:46 PM10/3/21
to Irit Katriel, Python-Dev
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)

Łukasz Langa

unread,
Oct 3, 2021, 4:11:15 PM10/3/21
to MRAB, pytho...@python.org

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

- Ł
signature.asc

Gregory P. Smith

unread,
Oct 3, 2021, 4:57:11 PM10/3/21
to Łukasz Langa, Python-Dev
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/

Barry Warsaw

unread,
Oct 3, 2021, 8:12:28 PM10/3/21
to Łukasz Langa, Irit Katriel
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

signature.asc

Steven D'Aprano

unread,
Oct 3, 2021, 11:43:03 PM10/3/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 12:19:50 AM10/4/21
to Python Dev
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

unread,
Oct 4, 2021, 1:30:36 AM10/4/21
to Jonathan Goble, Python Dev
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

unread,
Oct 4, 2021, 2:16:47 AM10/4/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 3:19:19 AM10/4/21
to Greg Ewing, Python Dev
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

unread,
Oct 4, 2021, 3:33:56 AM10/4/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 8:52:49 AM10/4/21
to Python Dev
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/

Calvin Spealman

unread,
Oct 4, 2021, 9:07:32 AM10/4/21
to Irit Katriel, python-dev
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/


--

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

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

Ammar Askar

unread,
Oct 4, 2021, 10:04:44 AM10/4/21
to Antoine Pitrou, python-dev
Throwing in another +1 for `except group`. 

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

Regards,
Ammar

Łukasz Langa

unread,
Oct 4, 2021, 10:37:11 AM10/4/21
to Calvin Spealman, Irit Katriel, python-dev

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?

signature.asc

Victor Stinner

unread,
Oct 4, 2021, 10:39:52 AM10/4/21
to Irit Katriel, python-dev
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/
--
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

unread,
Oct 4, 2021, 11:04:04 AM10/4/21
to pytho...@python.org

Jonathan Goble

unread,
Oct 4, 2021, 11:13:53 AM10/4/21
to Guido van Rossum, Python Dev
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

unread,
Oct 4, 2021, 11:53:38 AM10/4/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 12:10:45 PM10/4/21
to Jonathan Goble, Python Dev
The question was about which style to *recommend* (a la PEP-8).

MRAB

unread,
Oct 4, 2021, 12:22:37 PM10/4/21
to pytho...@python.org
> 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

unread,
Oct 4, 2021, 12:25:59 PM10/4/21
to gu...@python.org, Jonathan Goble, Python Dev
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/

Steven D'Aprano

unread,
Oct 4, 2021, 12:47:02 PM10/4/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 12:51:58 PM10/4/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 1:24:31 PM10/4/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 1:41:12 PM10/4/21
to Antoine Pitrou, python-dev
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.

Steve Dower

unread,
Oct 4, 2021, 2:37:37 PM10/4/21
to Antoine Pitrou, pytho...@python.org

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

unread,
Oct 4, 2021, 3:44:45 PM10/4/21
to pytho...@python.org


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/

Terry Reedy

unread,
Oct 4, 2021, 7:12:38 PM10/4/21
to pytho...@python.org
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

unread,
Oct 4, 2021, 8:13:05 PM10/4/21
to pytho...@python.org
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

unread,
Oct 5, 2021, 10:48:01 AM10/5/21
to pytho...@python.org