Mailman 3 May 2020 - python-committers

[RELEASE] Python 3.8.3 is now available
by Łukasz Langa 14 May '20

14 May '20

On behalf of the entire Python development community, and the currently serving Python release team in particular, I’m pleased to announce the release of Python 3.8.3, the third maintenance release of Python 3.8. You can find it here: https://www.python.org/downloads/release/python-383/ <https://www.python.org/downloads/release/python-383/> It contains two months worth of bug fixes. Detailed information about all changes made in 3.8.3 can be found in its change log <https://docs.python.org/release/3.8.3/whatsnew/changelog.html#python-3-8-3-…>. Note that compared to 3.8.2, version 3.8.3 also contains the changes introduced in 3.8.3rc1. The Python 3.8 series is the newest feature release of the Python language, and it contains many new features and optimizations. See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series. Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.4 planned for mid-July 2020. One more thing Unless blocked on any critical issue, Monday May 18th will be the release date of Python 3.9.0 beta 1. It’s a special release for us because this is when we lock the feature set for Python 3.9. If you can help testing the current available alpha release, that would be very helpful: https://www.python.org/downloads/release/python-390a6/ <https://www.python.org/downloads/release/python-390a6/> We hope you enjoy the new Python release! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ <https://www.python.org/psf/> Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>

1 0

Python GitHub Migration - Work Group Members needed
by Ewa Jodlowska 13 May '20

13 May '20

Hi! I just published a call for work group members here: https://pyfound.blogspot.com/2020/05/call-for-volunteers-python-github.html. The goal of the work group is to make sure community needs are represented in this migration. The hired PM <http://pyfound.blogspot.com/2020/05/pythons-migration-to-github-request-for…> will work with this work group and the GitHub team doing the physical migration. If anyone would like to take part in this work group, please apply here: https://forms.gle/jivuUdgViQPU4rKh8. Thank you, Ewa ----------------------- *As a non-profit organization, the PSF depends on sponsorships and donations to support the Python community. Check out our Annual Impact Report for more details: https://www.python.org/psf/annual-report/2019/ <https://www.python.org/psf/annual-report/2019/>* *Please contribute to PSF; we can't continue our work without your support! https://www.python.org/psf/donations/ <https://www.python.org/psf/donations/>*

1 0

Experimental isolated subinterpreters
by Victor Stinner 07 May '20

07 May '20

Hi, tl; dr I'm asking for your permission to merge the following PR :-) https://github.com/python/cpython/pull/19958 In bpo-40514, I added a new --with-experimental-isolated-subinterpreters configuration option. I chose to use a very long option name and to not document it on purpose: prevent users to use it "by mistake", without understanding its purpose. The option is related to "per-interpreter GIL": https://bugs.python.org/issue40512 It's a practical solution to be able to experiment quickly per-interpreter GIL without having to fix all issues at once. For example, it disables Unicode interned strings which is unsafe with multiple interpreters running in parallel. I added this #ifdef to encourage other core developers work on this project, and let early adopters test this experimental feature to give us their feedback. I hope that soon we will discover all places which need to be fixed, so it will help to better estimate how much work is needed to finish the implementation of per-interpreter GIL. Currently, the special build changes: * Per-interpreter GIL * Store the current Python thread state in a TLS * Disable dict, frame, tuple and list free list * Disable type method cache * Disable pymalloc: force usage of libc malloc * Disable the GC in subinterpreters * _xxsubinterpreters.run_string() releases the GIL I consider that's a reasonable small number of changes to get a cool feature (per-interpreter GIL), compared to the same of the CPython code base (637K lines). -- All these "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS" are temporary workarounds until a proper fix is designed. For example, some caches should be made "per-interpreter". Most changes are easy to write, but some other changes are non trivial. For example, I modified _PyThreadState_GET() and _PyThreadState_Swap() to use a Thread Local Storage (TLS) to get and set the current Python thread state. Currently, "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS" are not "visible" to users: it is only used in .c files and a few internal header files. But the following PR modify the public Include/object.h header file to make PyObject.ob_refcnt atomic: https://github.com/python/cpython/pull/19958 I would like to ensure that you are ok to put a few more temporary "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS" in CPython to speedup the development of subinterpreters running in parallel (per-interpreter GIL), or if you consider that it has gone too far and a Git fork would be better. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

4 5