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

[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-id...@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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/62ZX4T226BCRQE7ZNJPSJNNBAP735K2J/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

On 06/10/2021 17:35, Łukasz Langa wrote:
>
>> On 6 Oct 2021, at 18:05, Yury Selivanov  wrote:
[...]
>> I'll list a few reasons here:
>>
>> 1. `try: .. except group:` is a valid syntax today. And it will continue to 
>> be valid syntax. Having both `try: .. except group:` (catch exception 
>> `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 "", line 2, in 
> ZeroDivisionError: division by zero
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "", line 3, in 
> 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 "", line 1, in 
> NameError: name 'ar' is not defined. Did you mean: 'arg'?
> >>> def f():
> ...   ar
> ...
> >>> f()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", 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.

Now a moot point, but this could be a SyntaxWarning.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PB4ANBGW4M3DZDQA6C2PPXUPGPBZ3JJZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

try:

    ...

except group (KeyError, ZeroDivisionError) as error:

    ...


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


On 06/10/2021 15:36, Łukasz Langa wrote:
>> On 6 Oct 2021, at 16:01, Petr Viktorin  wrote:
>>
>> What about this:
>>
>> group = (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.
>
> - Ł
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LW4RJO5DTBO7CEYBTT2E7UTHCL6SCXK7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5N4FDYAW5AB2AXMGM6CBRSN6PK3IWMRD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GRVMPGZFNE67GE25SQCRCQWZQFZMA7PX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barry Scott]

> On 6 Oct 2021, at 18:48, Guido van Rossum  wrote:
> 
> On Wed, Oct 6, 2021 at 9:01 AM Brandt Bucher  > wrote:
> Another option (to remove the ambiguity) could be to move the “group” after 
> the expression. Bonus points for reading more clearly:
> 
> except 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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/RRHP6VRI5PUMRSIXKFQVR2E6L523NUVC/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

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

[Guido van Rossum]

On Wed, Oct 6, 2021 at 9:01 AM Brandt Bucher  wrote:

> Another option (to remove the ambiguity) could be to move the “group”
> after the expression. Bonus points for reading more clearly:
>
> except MemoryError group as e: …
> except (KeyError, IndexError) group as e: …
> except some + expression 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?)*

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

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

[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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EADN7QLDNPRF7WRSTGAQ5QGS5WNDDBQQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Calvin Spealman]

On Wed, Oct 6, 2021 at 12:01 PM Brandt Bucher 
wrote:

> Łukasz Langa wrote:
> > Joking aside, since we allow any expression after 'except' 'group' then
> this is indeed ambiguous. In theory!
>
> Another option (to remove the ambiguity) could be to move the “group”
> after the expression. Bonus 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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TW5I4Z3XKCSZC6IRXHNFVPZVLHEKI7O3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EAOMRSZJNBAO6PIFJ2SWC3CQQMIZSERL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

How about
```
try:
...
exceptgroup E1, E2:
...
``
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QY2I5EWUZZZWPCLS7YFFWR7RDRNGTCY7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YOTXVPFABO4YKQ7TSEA3NMGNF47MBH5T/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

> On 6 Oct 2021, at 18:05, Yury Selivanov  wrote:
> 
> I don't like `except group` or any variant with soft keywords.

As Brandt just commented, this proposal is a no go due to confusion with 
function calls. I'll respond below anyway because looking through it was an 
interesting experience


> 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 "", line 2, in 
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 3, in 
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 "", line 1, in 
NameError: name 'ar' is not defined. Did you mean: 'arg'?
>>> def f():
...   ar
...
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", 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.

- Ł



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HKY6KZO3267MUYWNJ7664QZIOLCTPZWM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barry Warsaw]

That might be exceptable.

-Barry

> On Oct 6, 2021, at 08:59, Brandt Bucher  wrote:
> 
> Łukasz Langa wrote:
>> Joking aside, since we allow any expression after 'except' 'group' then this 
>> is indeed ambiguous. In theory!
> 
> Another option (to remove the ambiguity) could be to move the “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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/TW5I4Z3XKCSZC6IRXHNFVPZVLHEKI7O3/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ICTKEKVNS4WA6VTGPHHJ2QVVGA6CKPJ3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

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

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KPZLQSC6ADVP26FI3MJIMARSOQRHVRCW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

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

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

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ABYR3PQF6LPQNAH6YINWJSE2KYXZM5YI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BUK2YFLH4TPIRTPG5JAYKNEWOBJTHC2B/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

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

How about a dedicated keyword such as "exceptany" or "exceptall"?

Regards

Antoine.


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

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

[Larry Hastings]

On 10/6/21 2:34 PM, Łukasz Langa wrote:
On 6 Oct 2021, at 12:06, Larry Hastings > wrote:


It seems like, for this to work, "group" would have to become a keyword.


No, just like `match` and `case` didn't have to.


This would play havoc with a lot of existing code.

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/

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

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

[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


On Tue, Oct 5, 2021 at 6:28 PM 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
>
> > On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev <
> python-dev@python.org> 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 -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/PFYQC7XMYFAGOPU5C2YVMND2BQSIJPRC/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/SZNDJPKT7WNWJHG4UDJ6D3BU6IN5ZXZO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TW5I4Z3XKCSZC6IRXHNFVPZVLHEKI7O3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

> On 6 Oct 2021, at 16:01, Petr Viktorin  wrote:
> 
> What about this:
> 
> group = (KeyboardInterrupt, MemoryError)
> other_group = (KeyError, IndexError)
> 
> try:
>   ...
> except group + other_group as error:
>   ...

Haha, let's see if we can write a Mersienne twister all inside an except 
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.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BL6PSZZCGLDQSMHTZTWRCP6G6KD6OK3K/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

On 06. 10. 21 15:34, Łukasz Langa wrote:


On 6 Oct 2021, at 12:06, Larry Hastings > wrote:


It seems like, for this to work, "group" would have to become a keyword.


No, just like `match` and `case` didn't have to.


This would play havoc with a lot of existing 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.


What about this:

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

try:
   ...
except group + other_group as error:
   ...
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KH7T6VDRYENBLLFNY7CAXFEVH4IILXZ7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

> On 6 Oct 2021, at 12:06, Larry Hastings  wrote:
> 
> It seems like, for this to work, "group" would have to become a keyword.
> 
No, just like `match` and `case` didn't have to.

> This would play havoc with a lot of existing code.
> 
Extraordinary claims require extraordinary evidence, Larry. 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".

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OQUS7X5D3WXYN4WKFRHIBHG25XDA247G/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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/

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


On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev 
 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PFYQC7XMYFAGOPU5C2YVMND2BQSIJPRC/
Code of Conduct: http://python.org/psf/codeofconduct/


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

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5E5OJAE6BZPANHII5QTYZ6KRGUPCS6WX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YHTK2JCUX4KZ6EDNYLAUEHXD2XNZTUDT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 
>  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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/PFYQC7XMYFAGOPU5C2YVMND2BQSIJPRC/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SZNDJPKT7WNWJHG4UDJ6D3BU6IN5ZXZO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 
>  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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/PFYQC7XMYFAGOPU5C2YVMND2BQSIJPRC/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MMDR72LKX2LHBWYVDNATEHLWIU2VTGY6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DTUIIVXGKA2MEBK6K3ZUOVHTLFRJC4HB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/O7V4G4DWEOXNWZB6MP4PKOXV46XKVT67/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PFYQC7XMYFAGOPU5C2YVMND2BQSIJPRC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Calvin Spealman]

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.


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


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UGX6J6OZFMNTZYNPPSPY5DUCPL4RMBWX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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)___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EAPQS342PWERAKVS4XHFYYSXVOK6LFHZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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, 
>  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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BFX2WFK4IFFUO2JRUBGKGLPPEFBRTIQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RGIAE2HMYQLPXWH5O5TNBNRXDQQ4UKAK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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/python-dev@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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GZOOLRO7RYWNKA3QWGNGXGXVV3KNNR4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EYS6Q53UN2KDBH2VM4KA7DVRL76KJYVX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rob Cliffe via Python-Dev]

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

On Oct 3, 2021, at 10:42, Łukasz Langa  wrote:


Speaking just for myself, the `except *` syntax always bothered me, but I 
couldn’t come up with anything better and it wasn’t enough for me to vote 
against PEP 654.  `except group` is nicer though, and 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7KHAN76UA5JRND2M2EMVLKML665KQDTC/
Code of Conduct: http://python.org/psf/codeofconduct/


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

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

[Steve Dower]

On 10/4/2021 5:47 PM, Antoine Pitrou wrote:

On Mon, 4 Oct 2021 12:18:35 -0400
Calvin Spealman  wrote:

On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum  wrote:


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


I think the very fact that it can't (or is difficult) be 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/52KJZMKMFTFHVMS3NXABNFQJRZNLKLX5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Calvin Spealman]

On Mon, Oct 4, 2021 at 12:48 PM Antoine Pitrou  wrote:

> On Mon, 4 Oct 2021 12:18:35 -0400
> Calvin Spealman  wrote:
> > On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum 
> wrote:
> >
> > > The question was about which style to *recommend* (a la PEP-8).
> > >
> >
> > I think the very fact that it 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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZLU5NYXVRCUM7AEEN55ITUQO43VDY6RE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MGGIWJ7YJVGCHYHLQTYQILFGDWL4UMR5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Glenn Linderman]

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

On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble  wrote:

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


You can't do that with our current lexer+parser.


Seems like a good reason to promote   "except group E"  instead of 
"except * E", as others have suggested.___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RHUNTWTPDJS5M4KPGHCRV4H34BD26BFO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CODOHGNW7F2AKMVPGLZZCMWLVKOINBIM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

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

How so?  If style checkers are 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZLU5NYXVRCUM7AEEN55ITUQO43VDY6RE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2021-10-04 16:02, Jonathan Goble wrote:
On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum > wrote:


On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble mailto:jcgob...@gmail.com>> wrote:

Therefore my vote is for requiring `except* E` and keeping
`except *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.)
The key phrase is """in any case we need to settle on a convention that 

we use in documentation, etc.""".
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RYJTNZVMNF54XVUIE4MMN6TXS2XRPTXO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Calvin Spealman]

On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum  wrote:

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

I think the very fact that it can't (or is difficult) be enforced, and so
in the wild we'll likely see variations that could lead to confusion, is
enough reason to find an alternative syntax.


> On Mon, Oct 4, 2021 at 8:03 AM Jonathan Goble  wrote:
>
>> On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum  wrote:
>>
>>> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble 
>>> wrote:
>>>
 Therefore my vote is for requiring `except* E` and 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.)
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DASEBDJ6CK6U4YHRKPJ7CNQQHVWEWOLQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZUUNY3BOXC3JV7GXBDXY54AEHMV334IV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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

On Mon, Oct 4, 2021 at 8:03 AM Jonathan Goble  wrote:

> On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum  wrote:
>
>> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble  wrote:
>>
>>> Therefore my vote is for requiring `except* E` and 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.)
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

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

[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 > 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NTAXBGISW5CGLR2CWQ7HN4CCMDNF6OPG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jonathan Goble]

On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum  wrote:

> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble  wrote:
>
>> Therefore my vote is for requiring `except* E` and keeping `except *E` as
>> a SyntaxError.
>>
>
> You can't do that with our current lexer+parser.
>

Then what is the purpose of 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.)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QVAC5VMVPJLMQ7PAGTAKJXYYOYAZE7CZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mark Shannon]

Another +1 for `except group` from me.

On 04/10/2021 2:57 pm, Ammar Askar wrote:

Throwing in another +1 for `except group`.

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


Regards,
Ammar

On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou > wrote:


On Sun, 3 Oct 2021 19:42:29 +0200
Łukasz Langa mailto: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 -- python-dev@python.org

To unsubscribe send an email to python-dev-le...@python.org

https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/INK6TSOGGODA4NZ3CI5MOXIAI4Z4CZ53/


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



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


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

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

[Victor Stinner]

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

Victor

On Sun, Oct 3, 2021 at 5:54 PM Irit Katriel via Python-Dev
 wrote:
>
>
> We wonder if people have a view on which of the following is clearer/better:
>
> 1. except *E as e:  //  except *(E1, E2) as e:
> 2. except* E as 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.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/A2REM55FHTETDZUPRVDWTVSXC273GHZW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

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

This is covered at length in the PEP. Those sections 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 


- Ł



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FHEWFNSDNZRHADGD3I2VVW66Y7DSNEI7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ammar Askar]

Throwing in another +1 for `except group`.

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

Regards,
Ammar

On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou  wrote:

> On Sun, 3 Oct 2021 19:42:29 +0200
> Łukasz Langa  wrote:
> >
> > -1
> >
> > If I could read the 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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/INK6TSOGGODA4NZ3CI5MOXIAI4Z4CZ53/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4ZUBUDQ4CGXYJAIYKMJMJBGUGGTODECF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Calvin Spealman]

On Sun, Oct 3, 2021 at 11:48 AM Irit Katriel via Python-Dev <
python-dev@python.org> wrote:

>
> We wonder if people have a view on which of the following is
> clearer/better:
>
> 1. except *E as e:  //  except *(E1, E2) as e:
> 2. except* E as e:  //  except* (E1, E2) as e:
>
> (The difference is 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.
>

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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XF2OZLWDMSL3LIRVU3VG6YZP47YXUCZO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

On Mon, Oct 4, 2021 at 1:30 AM Guido van Rossum  wrote:

> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble  wrote:
>
>> Therefore my vote is for requiring `except* E` and keeping `except *E` as
>> a SyntaxError.
>>
>
> You can't do that with our current lexer+parser.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/F2JUI7SWTQE6RJ4YYKQHJ233BERZHYWR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RC267HMZNQ5GPMQXIC5TQBSYQIXHBG34/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

On Sun, 3 Oct 2021 19:42:29 +0200
Łukasz Langa  wrote:
> 
> -1
> 
> If I could read the vertical line as a pipe character, the expression would 
> read "except or E as e".
> But I can't read it that way anyway. Instead, all I see is a lowercase 
> EXCEPTL.
> 
> My idea is this:
> 
> try:
> ...
> 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/INK6TSOGGODA4NZ3CI5MOXIAI4Z4CZ53/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On Mon, 4 Oct 2021 at 07:16, Greg Ewing  wrote:
>
> On 4/10/21 6:23 pm, Guido van Rossum wrote:
> > On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble  > > wrote:
> >
> > Therefore my vote is for requiring `except* E` and keeping `except
> > *E` as a SyntaxError.
> >
> > 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IKWKS6VYWFQ4XEXJ4XFYBLPRPXATKGGL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 4/10/21 6:23 pm, Guido van Rossum wrote:
On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > wrote:


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

You can't do that with our current lexer+parser.


I don't think it 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XQXJEGYAWBTAUQI3BEIXDZO4SERAJYWF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble  wrote:

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

You can't do that with our current lexer+parser.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

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

[Jonathan Goble]

On Sun, Oct 3, 2021 at 11:40 PM Steven D'Aprano  wrote:

> On Sun, Oct 03, 2021 at 11:34:55AM -0700, Guido van Rossum wrote:
>
> > I also think that the bar should be pretty high before we reopen the
> > *syntax* -- the PEP was approved without anyone (neither the SC, nor
> > Nathaniel, nor anyone 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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2TBZZSMZXNYFJNPLIESFNFDNDX5K6A5X/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5TRLGMHCOTEF3MMR6GR35TLG6TPG63VJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barry Warsaw]

On Oct 3, 2021, at 10:42, Łukasz Langa  wrote:
> 
> My idea is this:
> 
> try:
>...
> except group E as e:
>...
> except group E1, T2 as e:
>...
> 
> Should be doable given the magical match-case contextual keywords precedent. 
> This looks nice and is explicit, since you will always 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
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7KHAN76UA5JRND2M2EMVLKML665KQDTC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Gregory P. Smith]

On Sun, Oct 3, 2021 at 10:47 AM Łukasz Langa  wrote:

>
>  I know it's a bit late for bikeshedding this thing so if we want to be
> conservative and stick to the current syntactical options already defined
> in PEP 654, I'm voting Option 2 (given the awkwardness of the *(E1, E2)
> example).
>

+1 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 -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/T7QZJ575RFNYZ5KMYD66YMR2ZLNDVF56/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T5FOZVPJ2YWIQ25HRSQ5NZ6U3YMDKI7K/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

> On 3 Oct 2021, at 20:11, MRAB  wrote:
> 
> On 2021-10-03 18:50, Brandt Bucher wrote:
>> Łukasz Langa wrote:
>>> My idea is this:
>>> try:
>>>...
>>> except group E as e:
>>>...
>>> except group E1, T2 as e:
>>>...
>>> Should be doable given the magical match-case contextual keywords 
>>> 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
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DRC53PSOZR7RWH56U7EC7KBJLP6NG4EK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Sun, Oct 3, 2021 at 11:28 AM Irit Katriel via Python-Dev <
python-dev@python.org> wrote:

> We can drop except. Say:
>
> try:
>   ..
> handle T1:
>…
> handle T2:
>…
>
> Or ‘catch’, or something else.
>

We're going around in circles. We considered 'catch' early on, but decided
against 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?)*

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

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

[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  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").
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/FUTYE36MLFAWU72KTHDEQY5JFDA2PQ4G/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/K3I7552LB6O5XS3KWLC2C2U5XME43HQ5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FUTYE36MLFAWU72KTHDEQY5JFDA2PQ4G/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4FPTSD6VAIJD2WSP63KQUOQLDAOI3EWR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/44TWMI3PV3TKRL6ZJ4YU3GMQ6W43EHU5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

> On 3 Oct 2021, at 18:37, Steven D'Aprano  wrote:
> 
> On Sun, Oct 03, 2021 at 04:47:57PM +0100, Irit Katriel via Python-Dev wrote:
>> We wonder if people have a view on which of the following is clearer/better:
>> 
>> 1. except *E as e:  //  except *(E1, E2) as e:
> 
> That looks like you're 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
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T7QZJ575RFNYZ5KMYD66YMR2ZLNDVF56/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EA7E3EGQ6WB5O3ITPTN53C4CMFHDLBFK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7IKS3YFPFT5JO7QBJGNPMM33XUYKK7CK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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

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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BZ55ZMS5S5E7KPNP7AR7N2BSA35KVKF3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

On Sun, Oct 3, 2021 at 09:00 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, <
> python-dev@python.org> wrote:
>
>>
>> We wonder if people have a view on which of the following is
>> clearer/better:
>>
>> 1. except *E as e:  //  except *(E1, E2) as e:
>> 2. except* E as e:  //  except* (E1, E2) as e:
>>
>> (The difference is 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.
>>
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XNZNX2M2PQ24VEH5GWCGVFS5EY6XMRAX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WJGWKUPTTLZW37R3B5W33FRBSFMK3CUE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

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

On Sun, 3 Oct 2021, 16:50 Irit Katriel via Python-Dev, <
python-dev@python.org> wrote:

>
> We wonder if people have a view on which of the following is
> clearer/better:
>
> 1. except *E as e:  //  except *(E1, E2) as e:
> 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.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XNZNX2M2PQ24VEH5GWCGVFS5EY6XMRAX/
Code of Conduct: http://python.org/psf/codeofconduct/