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

2021-10-06 Thread 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:1755

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

2021-10-06 Thread 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

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

2021-10-06 Thread 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 "

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

2021-10-06 Thread Ł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

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

2021-10-06 Thread 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

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

2021-10-06 Thread 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 op

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

2021-10-06 Thread Ł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 st

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

2021-10-06 Thread 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:

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

2021-10-06 Thread 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 o

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

2021-10-06 Thread 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. E

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

2021-10-06 Thread 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"? Regard

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

2021-10-06 Thread 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 alter

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

2021-10-06 Thread Ł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". >

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

2021-10-06 Thread Ł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:

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

2021-10-06 Thread 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

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

2021-10-06 Thread Ł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

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

2021-10-06 Thread 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

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

2021-10-06 Thread 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 h

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

2021-10-06 Thread 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 poi

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

2021-10-06 Thread 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

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

2021-10-06 Thread 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

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

2021-10-06 Thread 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 Memory

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

2021-10-06 Thread 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

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

2021-10-06 Thread 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

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

2021-10-06 Thread 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 = (KeyboardInterrup

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

2021-10-06 Thread 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 >> `grou