[Python-Dev] [RELEASE] Python 3.10.4 and 3.9.12 are now available out of schedule

[Łukasz Langa]

Did anybody say cursed releases 
?
 Well, it turns out that 3.10.3 and 3.9.11 both shipped a regression which 
caused those versions not to build on Red Hat Enterprise Linux 6. While this 
11-year-old version is now out of maintenance support 
, it’s still used in 
production workloads. Some of those rely on Python 3.9 and/or 3.10. In 
particular, our own manylinux2010 

 image used to build widely compatible Linux wheels is based on CentOS 6. 
(Don’t worry, we do have newer manylinux* variants, see PEP 599 
 and PEP 600 
 for details.)

Due to the out-of-schedule release, the respective versions released today 
contain a very limited set of changes. Python 3.9.12 only contains 12 other bug 
fixes on top of 3.9.11. Python 3.10.4 only contains 10 other bug fixes on top 
of 3.10.3.

Get 3.10.4 here: Python Release 3.10.4 | Python.org 

Get 3.9.12 here: Python Release 3.9.12 | Python.org 

Hopefully, the third time’s a charm and we’ll return no sooner than May with 
the regularly scheduled bug fix releases of 3.9 and 3.10.

 
We
 hope you enjoy the new releases

Your friendly release team,
Łukasz Langa @ambv 
Pablo Galindo Salgado @pablogsal 
Ned Deily @nad 
Steve Dower @steve.dower 


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

[Python-Dev] Re: [RELEASE] Python 3.10.4 and 3.9.12 are now available out of schedule

[Damian Shaw]

I guess the docs aren't updated yet and the changes are listed as "Python
Next": https://docs.python.org/3.10/whatsnew/changelog.html#changelog ?

Damian(he/him)

On Thu, Mar 24, 2022 at 8:13 AM Łukasz Langa  wrote:

> Did anybody say cursed releases
> ?
> Well, it turns out that 3.10.3 and 3.9.11 both shipped a regression which
> caused those versions not to build on Red Hat Enterprise Linux 6. While
> this 11-year-old version is now out of maintenance support
> , it’s still
> used in production workloads. Some of those rely on Python 3.9 and/or 3.10.
> In particular, our own manylinux2010
> 
> image used to build widely compatible Linux wheels is based on CentOS 6.
> (Don’t worry, we do have newer manylinux* variants, see PEP 599
>  and PEP 600
>  for details.)
>
> Due to the out-of-schedule release, the respective versions released today
> contain a very limited set of changes. Python 3.9.12 only contains 12 other
> bug fixes on top of 3.9.11. Python 3.10.4 only contains 10 other bug fixes
> on top of 3.10.3.
>
> Get 3.10.4 here: Python Release 3.10.4 | Python.org
> 
> Get 3.9.12 here: Python Release 3.9.12 | Python.org
> 
>
> Hopefully, the third time’s a charm and we’ll return no sooner than May
> with the regularly scheduled bug fix releases of 3.9 and 3.10.
>
> We
> hope you enjoy the new releases
>
> Your friendly release team,
> Łukasz Langa @ambv 
> Pablo Galindo Salgado @pablogsal 
> Ned Deily @nad 
> Steve Dower @steve.dower 
> ___
> 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/SGB4B572RDPZ7SIJ5A6NZAI3Z3GKNIXA/
> 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/AHLDJISO2YFGXIZD3ON5F6QDPMVE3DD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.10.4 and 3.9.12 are now available out of schedule

[Pablo Galindo Salgado]

The docs will be updated later today, but the sources are already here:

https://docs.python.org/release/3.10.4/whatsnew/changelog.html#python-3-10-4-final

On Thu, 24 Mar 2022 at 13:44, Damian Shaw 
wrote:

> I guess the docs aren't updated yet and the changes are listed as "Python
> Next": https://docs.python.org/3.10/whatsnew/changelog.html#changelog ?
>
> Damian(he/him)
>
> On Thu, Mar 24, 2022 at 8:13 AM Łukasz Langa  wrote:
>
>> Did anybody say cursed releases
>> ?
>> Well, it turns out that 3.10.3 and 3.9.11 both shipped a regression which
>> caused those versions not to build on Red Hat Enterprise Linux 6. While
>> this 11-year-old version is now out of maintenance support
>> , it’s still
>> used in production workloads. Some of those rely on Python 3.9 and/or 3.10.
>> In particular, our own manylinux2010
>> 
>> image used to build widely compatible Linux wheels is based on CentOS 6.
>> (Don’t worry, we do have newer manylinux* variants, see PEP 599
>>  and PEP 600
>>  for details.)
>>
>> Due to the out-of-schedule release, the respective versions released
>> today contain a very limited set of changes. Python 3.9.12 only contains 12
>> other bug fixes on top of 3.9.11. Python 3.10.4 only contains 10 other bug
>> fixes on top of 3.10.3.
>>
>> Get 3.10.4 here: Python Release 3.10.4 | Python.org
>> 
>> Get 3.9.12 here: Python Release 3.9.12 | Python.org
>> 
>>
>> Hopefully, the third time’s a charm and we’ll return no sooner than May
>> with the regularly scheduled bug fix releases of 3.9 and 3.10.
>>
>> We
>> hope you enjoy the new releases
>>
>> Your friendly release team,
>> Łukasz Langa @ambv 
>> Pablo Galindo Salgado @pablogsal 
>> Ned Deily @nad 
>> Steve Dower @steve.dower 
>> ___
>> 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/SGB4B572RDPZ7SIJ5A6NZAI3Z3GKNIXA/
>> 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/AHLDJISO2YFGXIZD3ON5F6QDPMVE3DD5/
> 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/EXOYIWNOV6ZTFKBZUMNDDTMNTVZPF25T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Fabio Zadrozny]

>
> PEP 523 API added more private functions for code objects:
>
> * _PyEval_RequestCodeExtraIndex()
> * _PyCode_GetExtra()
> * _PyCode_SetExtra()
>
> The _PyEval_RequestCodeExtraIndex() function seems to be used by the
> pydevd debugger. The two others seem to be unused in the wild. I'm not
> sure if these ones should be moved to the internal C API. They can be
> left unchanged, since they don't use a type only defined by the
> internal C API.
>
Just to note, the pydevd/debugpy debuggers actually uses all of those APIs.

i.e.:

https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L187
https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L232
https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L311

The debugger already has workarounds because of changes to evaluation api
over time (see:
https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L491)
and I know 3.11 won't be different.

I'm ok with changes as I understand that this is a special API -- as long
as there's still a way to use it and get the information needed (the
debugger already goes through many hops because it needs to use many
internals of CPython -- in every new release it's a **really** big task to
update to the latest version as almost everything that the debugger relies
to make debugging fast changes across versions and I never really know if
it'll be possible to support it until I really try to do the port -- I
appreciate having less things in a public API so it's easier to have
extensions work in other interpreters/not recompiling on newer versions,
but please keep it possible to use private APIs which provides the same
access that CPython has to access things internally for special cases such
as the debugger).

Maybe later on that PEP from mark which allows a better debugger API could
alleviate that (but until then, if possible I appreciate it if there's some
effort not to break things unless really needed -- ideally with
instructions on how to port).

Anyways, to wrap up, the debugger already needs to be built with
`Py_BUILD_CORE_MODULE=1` anyways, so, I guess having it in a private API
(as long as it's still accessible in that case) is probably not a big issue
for the debugger and having setters/getters to set it instead of relying on
`state.interp.eval_frame` seems good to me.

Cheers,

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

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Fabio Zadrozny]

Em qui., 24 de mar. de 2022 às 15:39, Fabio Zadrozny 
escreveu:

> PEP 523 API added more private functions for code objects:
>>
>> * _PyEval_RequestCodeExtraIndex()
>> * _PyCode_GetExtra()
>> * _PyCode_SetExtra()
>>
>> The _PyEval_RequestCodeExtraIndex() function seems to be used by the
>> pydevd debugger. The two others seem to be unused in the wild. I'm not
>> sure if these ones should be moved to the internal C API. They can be
>> left unchanged, since they don't use a type only defined by the
>> internal C API.
>>
> Just to note, the pydevd/debugpy debuggers actually uses all of those APIs.
>
> i.e.:
>
>
> https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L187
>
> https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L232
>
> https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L311
>
> The debugger already has workarounds because of changes to evaluation api
> over time (see:
> https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L491)
> and I know 3.11 won't be different.
>
> I'm ok with changes as I understand that this is a special API -- as long
> as there's still a way to use it and get the information needed (the
> debugger already goes through many hops because it needs to use many
> internals of CPython -- in every new release it's a **really** big task to
> update to the latest version as almost everything that the debugger relies
> to make debugging fast changes across versions and I never really know if
> it'll be possible to support it until I really try to do the port -- I
> appreciate having less things in a public API so it's easier to have
> extensions work in other interpreters/not recompiling on newer versions,
> but please keep it possible to use private APIs which provides the same
> access that CPython has to access things internally for special cases such
> as the debugger).
>
> Maybe later on that PEP from mark which allows a better debugger API could
> alleviate that (but until then, if possible I appreciate it if there's some
> effort not to break things unless really needed -- ideally with
> instructions on how to port).
>
> Anyways, to wrap up, the debugger already needs to be built with
> `Py_BUILD_CORE_MODULE=1` anyways, so, I guess having it in a private API
> (as long as it's still accessible in that case) is probably not a big issue
> for the debugger and having setters/getters to set it instead of relying on
> `state.interp.eval_frame` seems good to me.
>
> Cheers,
>
> Fabio
>
>

I think the main issue here is the compatibility across the same version
though... is it possible to have some kind of guarantee on private APIs
that something won't change across micro-releases?

I.e.: having the frame evaluation function change across major releases and
having them be reworked seems reasonable, but then having the frame
evaluation be changed across micro-releases wouldn't be.

So, I'm ok in pushing things to the internal API, but then I still would
like guarantees about the compatibility of that API in the same major
release (otherwise those setters/getters/frame evaluation should probably
remain on the public API if the related structure was moved to the internal
API).

Cheers,

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

[Python-Dev] Re: Python Language Summit at PyCon 2022 in Salt Lake City

[Mariatta]

Last call!

Please sign up for the language summit before this Saturday.

We received a number of topic proposals in the last few days, and we still
have room for more, so don't delay.

Full details at: https://us.pycon.org/2022/events/language-summit/

When: Wednesday, April 27, 2022
Where: in person during PyCon US, Salt Palace Convention Center, room TBD

Sign up to attend:  https://forms.gle/CS8B6wJdcaN3rtWV8  (closes March 25
th, 2022 AoE)
Sign up to discuss a topic: https://forms.gle/LAFE6TTYi15jL5RaA (closes
March 25th, 2022 AoE)



On Mon, Mar 21, 2022 at 9:14 AM Mariatta  wrote:

> Hi everybody,
>
> Just sending out a reminder to sign up for the language summit. The
> signups are open until EOD Friday this week.
>
> *When:* Wednesday, April 27, 2022
> *Where:* in person during PyCon US, Salt Palace Convention Center, room
> TBD
>
> *Sign up to attend:*  https://forms.gle/CS8B6wJdcaN3rtWV8
>  (closes March 25 th, 2022 AoE)
> *Sign up to discuss a topic:* https://forms.gle/LAFE6TTYi15jL5RaA (closes
> March 25th, 2022 AoE)
>
> Currently the room is more than half full! We have close to 30
> attendees signing up, but we haven't received a lot of presentation
> proposals yet. (less than 5)
>
> From the signups, it seems like attendees are interested in discussing
> topics like: Cinder, Faster CPython, and various PEPs. So if you've been
> thinking about submitting a proposal, please do it soon!
>
> Thank you,
>
> Mariatta, Łukasz, & Senthil
>
>
___
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/O7CY7EQZRBLR3KU6JA6CBBJOQWYXNMXA/
Code of Conduct: http://python.org/psf/codeofconduct/