[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: python3.10 compilation on OpenBSD: running into ssl issues

[Sandeep Gupta]

Thank you for super quick fix ). Works like charm.

Thanks
S

On Wednesday, October 6, 2021, Christian Heimes 
wrote:

> On 06/10/2021 09.06, Sandeep Gupta wrote:
>
>> Tried with openssl. Some progress but no success.  The configure checks
>> went through find.
>>  >configure:17536: checking for openssl/ssl.h in
>> /home/kabira/DrivingRange//project_versa/Build
>>  >s/openssl-1.1.1l
>>  >configure:17543: result: yes
>>  >configure:17559: checking whether compiling and linking against OpenSSL
>> works
>>  >Trying link with OPENSSL_LDFLAGS=-L/home/kabira
>> /DrivingRange//project_versa/Builds/openssl-1.
>>  >1.1l/lib; OPENSSL_LIBS=-lssl -lcrypto; OPENSSL_INCLUDES=-I/home/kabir
>> a/DrivingRange//project_
>>  >versa/Builds/openssl-1.1.1l/include
>>
>> But for some reason module could not be imported. I could find any errors
>> related to import.
>> There were no compilation errors:
>>
>>  >Following modules built successfully but were removed because they
>> could not be imported:
>>  >_hashlib  _ssl  readline
>>
>
> [...]
>
> *** WARNING: renaming "_ssl" since importing it failed: Cannot load
>> specified object
>> *** WARNING: renaming "_hashlib" since importing it failed: Cannot load
>> specified object
>>
>
> OpenBSD uses clang C compiler. The new --with-openssl-rpath=auto option
> was only tested with GCC. It turned out that Python's distutils package
> didn't support rpath with clang. The bugfix https://bugs.python.org/issue4
> 5371 will be available in upcoming release Python 3.10.1.
>
> In the mean time you either need to apply the patch from the issue
> manually or figure out the right environment variables to add correct rpath
> yourself.
>
> I'm sorry for the inconvenience. We don't have any CI for OpenBSD.
> Apparently this feature was never tested on OpenBSD during the release
> candidate phase either.
>
> Christian
>
___
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/XFXP4LRY3WWWXHZLKQTZI7LMRBQOQCAF/
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: python3.10 compilation on OpenBSD: running into ssl issues

[Sandeep Gupta]

Tried with openssl. Some progress but no success.  The configure checks
went through find.
>configure:17536: checking for openssl/ssl.h in
/home/kabira/DrivingRange//project_versa/Build
>s/openssl-1.1.1l
>configure:17543: result: yes
>configure:17559: checking whether compiling and linking against OpenSSL
works
>Trying link with
OPENSSL_LDFLAGS=-L/home/kabira/DrivingRange//project_versa/Builds/openssl-1.
>1.1l/lib; OPENSSL_LIBS=-lssl -lcrypto;
OPENSSL_INCLUDES=-I/home/kabira/DrivingRange//project_
>versa/Builds/openssl-1.1.1l/include

But for some reason module could not be imported. I could find any errors
related to import.
There were no compilation errors:

>Following modules built successfully but were removed because they could
not be imported:
>_hashlib  _ssl  readline


There area number of warnings regarding type conversions. Just attaching
that for sanity check.
This readline error is particulary wierd. ==>
 ldd: /usr/lib/libreadline.a: not an ELF executable

>>
Python/pytime.c:160:10: warning: implicit conversion from 'long long' to
'double' changes value from 9223372036854775807 to 9223372036854775808
[-Wimplicit-const-int-float-conversion]
if (!_Py_InIntegralTypeRange(time_t, intpart)) {
 ^~~~
./Include/pymath.h:228:82: note: expanded from macro
'_Py_InIntegralTypeRange'
#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v &&
v <= _Py_IntegralTypeMax(type))

  ~~ ^
./Include/pymath.h:221:124: note: expanded from macro '_Py_IntegralTypeMax'
#define _Py_IntegralTypeMax(type) ((_Py_IntegralTypeSigned(type)) ?
(type)1 << (sizeof(type)*CHAR_BIT - 2)) - 1) << 1) + 1) : ~(type)0)
`
~~^~~
Python/pytime.c:213:14: warning: implicit conversion from 'long long' to
'double' changes value from 9223372036854775807 to 9223372036854775808
[-Wimplicit-const-int-float-conversion]
if (!_Py_InIntegralTypeRange(time_t, intpart)) {
 ^~~~
./Include/pymath.h:228:82: note: expanded from macro
'_Py_InIntegralTypeRange'
#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v &&
v <= _Py_IntegralTypeMax(type))

  ~~ ^
./Include/pymath.h:221:124: note: expanded from macro '_Py_IntegralTypeMax'
#define _Py_IntegralTypeMax(type) ((_Py_IntegralTypeSigned(type)) ?
(type)1 << (sizeof(type)*CHAR_BIT - 2)) - 1) << 1) + 1) : ~(type)0)

 ~~^~~
Python/pytime.c:398:10: warning: implicit conversion from 'long long' to
'double' changes value from 9223372036854775807 to 9223372036854775808
[-Wimplicit-const-int-float-conversion]
if (!_Py_InIntegralTypeRange(_PyTime_t, d)) {
 ^
./Include/pymath.h:228:82: note: expanded from macro
'_Py_InIntegralTypeRange'
#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v &&
v <= _Py_IntegralTypeMax(type))

  ~~ ^
./Include/pymath.h:221:124: note: expanded from macro '_Py_IntegralTypeMax'
#define _Py_IntegralTypeMax(type) ((_Py_IntegralTypeSigned(type)) ?
(type)1 << (sizeof(type)*CHAR_BIT - 2)) - 1) << 1) + 1) : ~(type)0)

 ~~^~~
3 warnings generated.
./Modules/_threadmodule.c:1644:26: warning: implicit conversion from
'_PyTime_t' (aka 'long long') to 'double' changes value from
9223372036854775 to 9223372036854776 [-Wimplicit-const-int-float-conversion]
double timeout_max = (_PyTime_t)PY_TIMEOUT_MAX * 1e-6;
 ^ ~
1 warning generated.
ldd: /usr/lib/libreadline.a: not an ELF executable
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/readline.c:1258:37:
warning: assigning to 'char *' from 'const char *' discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
completer_word_break_characters =
^
1 warning generated.
*** WARNING: renaming "readline" since importing it failed: dynamic module
does not define module export function (PyInit_readline)
*** WARNING: renaming "_ssl" since importing it failed: Cannot load
specified object
*** WARNING: renaming "_hashlib" since importing it failed: Cannot load
specified object
renaming build/scripts-3.10/pydoc3 to build/scripts-3.10/pydoc3.10
renaming build/scripts-3.10/idle3 to build/scripts-3.10/idle3.10
renaming build/scripts-3.10/2to3 to build/scripts-3.10/2to3-3.10
*** Warning in
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0:
'$(LLVM_PROF_MERGER)' expands to '' while building build_all_merge_profile
(Makefile:539)
Python/pytime.c:160:10: warning: 

[Python-Dev] Re: python3.10 compilation on OpenBSD: running into ssl issues

[Christian Heimes]

On 06/10/2021 09.06, Sandeep Gupta wrote:
Tried with openssl. Some progress but no success.  The configure checks 
went through find.
 >configure:17536: checking for openssl/ssl.h in 
/home/kabira/DrivingRange//project_versa/Build

 >s/openssl-1.1.1l
 >configure:17543: result: yes
 >configure:17559: checking whether compiling and linking against 
OpenSSL works
 >Trying link with 
OPENSSL_LDFLAGS=-L/home/kabira/DrivingRange//project_versa/Builds/openssl-1.
 >1.1l/lib; OPENSSL_LIBS=-lssl -lcrypto; 
OPENSSL_INCLUDES=-I/home/kabira/DrivingRange//project_

 >versa/Builds/openssl-1.1.1l/include

But for some reason module could not be imported. I could find any 
errors related to import.

There were no compilation errors:

 >Following modules built successfully but were removed because they 
could not be imported:

 >_hashlib              _ssl                  readline


[...]

*** WARNING: renaming "_ssl" since importing it failed: Cannot load 
specified object
*** WARNING: renaming "_hashlib" since importing it failed: Cannot load 
specified object


OpenBSD uses clang C compiler. The new --with-openssl-rpath=auto option 
was only tested with GCC. It turned out that Python's distutils package 
didn't support rpath with clang. The bugfix 
https://bugs.python.org/issue45371 will be available in upcoming release 
Python 3.10.1.


In the mean time you either need to apply the patch from the issue 
manually or figure out the right environment variables to add correct 
rpath yourself.


I'm sorry for the inconvenience. We don't have any CI for OpenBSD. 
Apparently this feature was never tested on OpenBSD during the release 
candidate phase either.


Christian
___
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/RAKDWHTH7TMUYEWJJFNOPLKLBBDXZBED/
Code of Conduct: http://python.org/psf/codeofconduct/