[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[Nick Coghlan]

On Tue, 28 Sep 2021, 6:55 am Brett Cannon,  wrote:

>
>
> On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
> python-dev@python.org> wrote:
>
>>
>> However the stable ABI is still a second class citizen as it is still
>> not possible (AFAIK) to specify a wheel name that doesn't need to
>> explicitly include each supported Python version (rather than a minimum
>> stable ABI version).
>>
>
> Actually you can do this. The list of compatible wheels for a platform
> starts at CPython 3.2 when the stable ABI was introduced and goes forward
> to the version of Python you are running. So you can build a wheel file
> that targets the oldest version of CPython that you are targeting and its
> version of the stable ABI and it is considered forward compatible. See
> `python -m pip debug --verbose` for the complete list of wheel tags that
> are supported for an interpreter.
>

I think Phil's point is a build side one: as far as I know, the process for
getting one of those more generic file names is still to build a wheel with
an overly precise name for the stable ABI declarations used, and then
rename it.

The correspondence between "I used these stable ABI declarations in my
module build" and "I can use this more broadly accepted wheel name" is
currently obscure enough that I couldn't tell you off the top of my head
how to do it, and I contributed to the design of both sides of the equation.

Actually improving the build ergonomics would be hard (and outside
CPython's own scope), but offering a table in the stable ABI docs giving
suggested wheel tags for different stable ABI declarations should be
feasible, and would be useful to both folks renaming already built wheels
and anyone working on improving the build automation tools.

Cheers,
Nick.


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

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[Petr Viktorin]

On 05. 10. 21 8:59, Nick Coghlan wrote:
On Tue, 28 Sep 2021, 6:55 am Brett Cannon, > wrote:




On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev
mailto:python-dev@python.org>> wrote:


However the stable ABI is still a second class citizen as it is
still
not possible (AFAIK) to specify a wheel name that doesn't need to
explicitly include each supported Python version (rather than a
minimum
stable ABI version).


Actually you can do this. The list of compatible wheels for a
platform starts at CPython 3.2 when the stable ABI was introduced
and goes forward to the version of Python you are running. So you
can build a wheel file that targets the oldest version of CPython
that you are targeting and its version of the stable ABI and it is
considered forward compatible. See `python -m pip debug --verbose`
for the complete list of wheel tags that are supported for an
interpreter.


I think Phil's point is a build side one: as far as I know, the process 
for getting one of those more generic file names is still to build a 
wheel with an overly precise name for the stable ABI declarations used, 
and then rename it.


The correspondence between "I used these stable ABI declarations in my 
module build" and "I can use this more broadly accepted wheel name" is 
currently obscure enough that I couldn't tell you off the top of my head 
how to do it, and I contributed to the design of both sides of the equation.


Actually improving the build ergonomics would be hard (and outside 
CPython's own scope), but offering a table in the stable ABI docs giving 
suggested wheel tags for different stable ABI declarations should be 
feasible, and would be useful to both folks renaming already built 
wheels and anyone working on improving the build automation tools.



Indeed, thinking about proper wheel tags, and adding support for them in 
both pip/installer and setuptools/build/poetry/etc., would be a very 
helpful way to contribute to the stable ABI.

I don't think I will be able to get to this any time soon.

The current `abi3` tag doesn't encode the minimum ABI version. AFAIK 
that info should go in the "Requires-Python" wheel metadata, but there's 
not automation or clear guides for that. Putting it in the wheel tag 
might be a good idea.


There are vague ideas floating around about removing old stable ABI 
features (hopefully after they're deprecated for 5-10 years); if there's 
a new wheel tag scheme it should be made with that possibility in mind.

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

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[Phil Thompson via Python-Dev]

On 05/10/2021 07:59, Nick Coghlan wrote:

On Tue, 28 Sep 2021, 6:55 am Brett Cannon,  wrote:




On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:



However the stable ABI is still a second class citizen as it is still
not possible (AFAIK) to specify a wheel name that doesn't need to
explicitly include each supported Python version (rather than a 
minimum

stable ABI version).



Actually you can do this. The list of compatible wheels for a platform
starts at CPython 3.2 when the stable ABI was introduced and goes 
forward
to the version of Python you are running. So you can build a wheel 
file
that targets the oldest version of CPython that you are targeting and 
its

version of the stable ABI and it is considered forward compatible. See
`python -m pip debug --verbose` for the complete list of wheel tags 
that

are supported for an interpreter.



I think Phil's point is a build side one: as far as I know, the process 
for
getting one of those more generic file names is still to build a wheel 
with

an overly precise name for the stable ABI declarations used, and then
rename it.

The correspondence between "I used these stable ABI declarations in my
module build" and "I can use this more broadly accepted wheel name" is
currently obscure enough that I couldn't tell you off the top of my 
head
how to do it, and I contributed to the design of both sides of the 
equation.


Actually improving the build ergonomics would be hard (and outside
CPython's own scope), but offering a table in the stable ABI docs 
giving

suggested wheel tags for different stable ABI declarations should be
feasible, and would be useful to both folks renaming already built 
wheels

and anyone working on improving the build automation tools.


Actually I was able to do what I wanted without renaming wheels...

Specify 'py_limited_api=True' as an argument to Extension() (using 
setuptools v57.0.0).


Specify...

[bdist_wheel]
py_limited_api = cp36

...in setup.cfg (using wheel v0.34.2).

The resulting wheel has a Python tag of 'cp36' and an ABI tag of 'abi3' 
for all platforms, which is interpreted by the current version of pip 
exactly as I want.


I'm not sure if this is documented anywhere.

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

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[Abdur-Rahmaan Janhangeer]

> What I have heard repeatedly, from people who are paid to know, is that most 
> users don’t care about the latest features, and would rather stick to a 
> release until it becomes unsupported. (Extreme example: Python 2.)

Just a quick note: Until black supports py3.10 fully, I'm sticking with py3.9
for dear life.

Kind Regards,

Abdur-Rahmaan Janhangeer
about | blog
github
Mauritius
___
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/IJU6XLQHNNT5PFYTNLT2IPRYPRRTZLWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[Thomas Grainger]

I think that's unfortunate, you can still use and format the subset of Python 
3.10 syntax with black.

You already do this on python 3.9 for example black doesn't support 
parenthesized with
___
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/5LWYHTZYZ4WJB7PSN3HWHECITMNHBT6O/
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

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

[Sandeep Gupta]

Trying to compile python3.10 on openbsd 7.0 on Pi4. It seems to run into
several openssl issue.  I have installed openssl as I couldn't find
libreSSL in the package manager.

The configure seems to passthe ssl test.

configure:17559: checking whether compiling and linking against OpenSSL
works
Trying link with OPENSSL_LDFLAGS=; OPENSSL_LIBS= -lssl -lcrypto;
OPENSSL_INCLUDES=
configure:17581: cc -pthread -o conftest  conftest.c  -lssl -lcrypto
-lpthread  -lutil -lm >&5
configure:17581: $? = 0
configure:17583: result: yes


I get following errors:

>> don't know why this happens
ldd: /usr/lib/libreadline.a: not an ELF executable

>>Errors when building _ssl module

cc -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code
-DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-function-declaration -fvisibility=hidden
-I./Include/internal -I./Include
-I/home/kabira/DrivingRange/project_versa/Builds/Python-3.10.0/include -I.
-I/usr/local/include
-I/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Include
-I/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0 -c
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c
-o
build/temp.openbsd-7.0-arm64-3.10/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.o
In file included from
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:390:
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl/debughelpers.c:180:5:
error: implicit declaration of function 'SSL_CTX_set_keylog_callback' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
SSL_CTX_set_keylog_callback(self->ctx, NULL);
^
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:1842:29:
error: implicit declaration of function 'SSL_get0_verified_chain' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
STACK_OF(X509) *chain = SSL_get0_verified_chain(self->ssl);
^
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:1842:21:
warning: incompatible integer to pointer conversion initializing 'struct
stack_st_X509 *' with an expression of type 'int' [-Wint-conversion]
STACK_OF(X509) *chain = SSL_get0_verified_chain(self->ssl);
^   ~~
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:2349:18:
error: implicit declaration of function 'SSL_write_ex' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
retval = SSL_write_ex(self->ssl, b->buf, (size_t)b->len, &count);


/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:2349:18:
note: did you mean 'SSL_write'?
/usr/include/openssl/ssl.h:1415:6: note: 'SSL_write' declared here
int SSL_write(SSL *ssl, const void *buf, int num);
^
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:2501:18:
error: implicit declaration of function 'SSL_read_ex' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
retval = SSL_read_ex(self->ssl, mem, (size_t)len, &count);
 ^
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:2501:18:
note: did you mean 'SSL_read'?
/usr/include/openssl/ssl.h:1413:6: note: 'SSL_read' declared here
int SSL_read(SSL *ssl, void *buf, int num);
^
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:3542:30:
error: implicit declaration of function 'SSL_CTX_get_num_tickets' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
return PyLong_FromSize_t(SSL_CTX_get_num_tickets(self->ctx));
 ^
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:3560:9:
error: implicit declaration of function 'SSL_CTX_set_num_tickets' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (SSL_CTX_set_num_tickets(self->ctx, num) != 1) {
^
/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_ssl.c:3574:28:
error: implicit declaration of function 'SSL_CTX_get_security_level' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
return PyLong_FromLong(SSL_CTX_get_security_level(self->ctx));
   ^
cc -pthread -shared -fPIC
build/temp.openbsd-7.0-arm64-3.10/home/kabira/DrivingRange/project_versa/downloads/Python-3.10.0/Modules/_testcapimodule.o
-L/home/kabira/DrivingRange/project_versa/Builds/Python-3.10.0/lib
-L/usr/local/lib -o build/lib.openbsd-7.0-arm64-3.10/_
testcapi.cpython-310.so


> and errors building _hashlib module

cc -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code
-DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-fun

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

[Christian Heimes]

On 05/10/2021 16.40, Sandeep Gupta wrote:
Trying to compile python3.10 on openbsd 7.0 on Pi4. It seems to run into 
several openssl issue.  I have installed openssl as I couldn't find 
libreSSL in the package manager.


Your installation is picking up header files from LibreSSL. Python 3.10 
requires a fully OpenSSL 1.1.1 API compliant OpenSSL. LibreSSL is 
missing a bunch of required features.


Please follow the instruction 
https://docs.python.org/3.10/using/unix.html#custom-openssl to compile, 
install, and use a custom installation of OpenSSL. I recommend that you 
use the latest OpenSSL 1.1.1 version.


Regards,
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/BK22LJ5LICXUMIU6MYB746FSZ57KJX2T/
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] Thanks for your work in Python 3.10

[Pablo Galindo Salgado]

Hi everyone,

Now that 3.10.0 is finally released I wanted to take the time to thank you
all for all your fantastic
work this past year. Is because of the sum of all your fantastic work that
Python 3.10 is going to be
such a fantastic release. No matter if you have been working in fixing
bugs, adding features,
improving the documentation, reviewing contributor PRs, helping with the
infrastructure, helping with
the buildbot fleet, triaging bugs or discussing PEPs and features, your
work is tremendously appreciated:
you make a tremendous impact in Python and its community.

I also wanted to make sure to thank again all the people that helped with
the release itself and with the
numerous release blockers and also for your patience when I had to delay
your feature to 3.11 or your
bugfix to 3.10.1.

It has been a privilege to be able to release the result of your work to
the community!

Thank you all, your work really makes a difference.

Regards from sunny London,
Pablo Galindo Salgado
___
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/YIZ4XLYW25UA3UVQLQHHIEYUK77ZE5XE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[Abdur-Rahmaan Janhangeer]

Thanks for info, that's becoming a black spot in the tool it seems.

It's more for production codes, now I can give it a try!

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
___
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/26XIXA6EQR3N22YERVBWRUSKHDMZLM46/
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: Thanks for your work in Python 3.10

[Simon Cross]

Thank you for managing the release, Pablo!

And for the awesome astrophysics snippets. :D
___
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/Y6RVLW6W7WLJNVQE6GXZHNUAUUKWP5LL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Thanks for your work in Python 3.10

[Charalampos Stratakis]

Seconding that.

I'd also like to add a big thank you to all the contributors for engaging
through each release with the downstream Python redistributors as well,
hearing us, working with us, helping us shape the future of a big part of
the linux (and not only) ecosystem.

On Tue, Oct 5, 2021 at 6:26 PM Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> Now that 3.10.0 is finally released I wanted to take the time to thank you
> all for all your fantastic
> work this past year. Is because of the sum of all your fantastic work that
> Python 3.10 is going to be
> such a fantastic release. No matter if you have been working in fixing
> bugs, adding features,
> improving the documentation, reviewing contributor PRs, helping with the
> infrastructure, helping with
> the buildbot fleet, triaging bugs or discussing PEPs and features, your
> work is tremendously appreciated:
> you make a tremendous impact in Python and its community.
>
> I also wanted to make sure to thank again all the people that helped with
> the release itself and with the
> numerous release blockers and also for your patience when I had to delay
> your feature to 3.11 or your
> bugfix to 3.10.1.
>
> It has been a privilege to be able to release the result of your work to
> the community!
>
> Thank you all, your work really makes a difference.
>
> Regards from sunny London,
> Pablo Galindo Salgado
> ___
> 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/YIZ4XLYW25UA3UVQLQHHIEYUK77ZE5XE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
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/OLLLFPUIRIPK32AXMSDFYLRLZC7J4BVM/
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

[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

[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

[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

[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

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