Mailman 3 - python-committers

[RELEASE] Python 3.9.13 is now available
by Łukasz Langa 17 May '22

17 May '22

This is the thirteenth maintenance release of Python 3.9. Get it here: Python 3.9.13 <https://www.python.org/downloads/release/python-3913/> According to the release calendar specified in PEP 596 <https://www.python.org/dev/peps/pep-0596/>, Python 3.9.13 is the final regular maintenance release. Starting now, the 3.9 branch will only accept security fixes and releases of those will be made in source-only form until October 2025. This is a milestone moment for me as it means that now both of my release series are security-only. My work as release manager enters its final stage. I’m not crying, you’re crying! 🥲 Compared to the 3.8 series, this last regular bugfix release is still pretty active at 166 commits since 3.9.12. In comparison, version 3.8.10, the final regular bugfix release of Python 3.8, included only 92 commits. However, it’s likely that it was 3.8 that was special here with the governance changes occupying core developers’ minds. For reference, version 3.7.8, the final regular bugfix release of Python 3.7, included 187 commits. In any case, 166 commits is quite a few changes, some of which being pretty important fixes. Take a look at the change log <https://docs.python.org/release/3.9.13/whatsnew/changelog.html> for details. <https://discuss.python.org/t/python-3-9-13-is-now-available/15815#major-new…>Major new features of the 3.9 series, compared to 3.8 Some of the new major new features and changes in Python 3.9 are: PEP 573 <https://www.python.org/dev/peps/pep-0573/>, Module State Access from C Extension Methods PEP 584 <https://www.python.org/dev/peps/pep-0584/>, Union Operators in dict PEP 585 <https://www.python.org/dev/peps/pep-0585/>, Type Hinting Generics In Standard Collections PEP 593 <https://www.python.org/dev/peps/pep-0593/>, Flexible function and variable annotations PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence PEP 614 <https://www.python.org/dev/peps/pep-0614/>, Relaxing Grammar Restrictions On Decorators PEP 615 <https://www.python.org/dev/peps/pep-0615/>, Support for the IANA Time Zone Database in the Standard Library PEP 616 <https://www.python.org/dev/peps/pep-0616/>, String methods to remove prefixes and suffixes PEP 617 <https://www.python.org/dev/peps/pep-0617/>, New PEG parser for CPython BPO 38379 <https://bugs.python.org/issue38379>, garbage collection does not block on resurrected objects; BPO 38692 <https://bugs.python.org/issue38692>, os.pidfd_open added that allows process management without races and signals; BPO 39926 <https://bugs.python.org/issue39926>, Unicode support updated to version 13.0.0; BPO 1635741 <https://bugs.python.org/issue1635741>, when Python is initialized multiple times in the same process, it does not leak memory anymore; A number of Python builtins (range, tuple, set, frozenset, list, dict) are now sped up using PEP 590 <https://www.python.org/dev/peps/pep-0590> vectorcall; A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, _functools, _json, _locale, operator, resource, time, _weakref) now use multiphase initialization as defined by PEP 489 <https://www.python.org/dev/peps/pep-0489/>; A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384 <https://www.python.org/dev/peps/pep-0384/>. You can find a more comprehensive list in this release’s “What’s New <https://docs.python.org/release/3.9.13/whatsnew/3.9.html>” document. <https://discuss.python.org/t/python-3-9-13-is-now-available/15815#we-hope-y…>We hope you enjoy Python 3.9! 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. 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

Announcing the Python Language Summit 2022 blog posts
by Mariatta 11 May '22

11 May '22

The blog posts about presentations and discussions from Python Language Summit 2022 are now up for your enjoyment. Main article: https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit_016788… - Python without the GIL <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-python…> , Sam Gross - Reaching a per-interpreter GIL <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-per.ht…> , Eric Snow - The “Faster CPython” project: 3.12 and beyond <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit_2.html> , Mark Shannon - WebAssembly: Python in the browser and beyond <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-python…> , Christian Heimes - F-strings in the grammar <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-f.html>, Pablo Galindo Salgado - Cinder Async Optimisations <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit_60.html>, Itamar Ostricher - The issue and PR backlog <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-dealin…>, Irit Katriel - The path forward for immortal objects <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit_11.html>, Eddie Elizondo and Eric Snow - Lightning talks <https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit.html>, short presentations by Carl Meyer, Thomas Wouters, Kevin Modzelewski, and Larry Hastings Thanks Alex Waygood for the write ups! Also thank you to all presenters and attendees for great content and discussions. This is the fourth Language Summit that I co-chaired with Łukasz, and also my last one. I’m stepping down from this responsibility to free up my time to take on other responsibilities and challenges. I’m grateful to have been given this opportunity to serve the Python community. This has been a great privilege and valuable experience. Thank you Lukasz for working alongside me the past four years, and Senthil for helping out this year. Thank you!

1 0

Welcome Erlend Aasland to the team!
by Brett Cannon 09 May '22

09 May '22

EOM

2 1

[RELEASE] The first Python 3.11 beta (3.11.0b1) is available - Feature freeze is here
by Pablo Galindo Salgado 08 May '22

08 May '22

We did it, team!! After quite a bumpy release process and a bunch of last-time fixes, we have reached **beta 1** and **feature freeze**. What a ride eh? You can get the shiny new release artefacts from here: https://www.python.org/downloads/release/python-3110b1/ ## This is a beta preview of Python 3.11 Python 3.11 is still in development. 3.11.0b1 is the first of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We **strongly encourage** maintainers of third-party Python projects to **test with 3.11** during the beta phase and report issues found to [the Python bug tracker](https://bugs.python.org) as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2021-08-02). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.11.0rc1, the first release candidate. To achieve that, it will be **extremely important** to get as much exposure for 3.11 as possible during the beta phase. Please keep in mind that this is a preview release and its use is **not** recommended for production environments. # Major new features of the 3.11 series, compared to 3.10 Python 3.11 is still in development. This release, 3.11.0b1 is the **first** of four beta releases. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. Many new features for Python 3.11 are still being planned and written. Among the new major new features and changes so far: * [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include Fine-Grained Error Locations in Tracebacks * [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups and except* * [PEP 673](https://www.python.org/dev/peps/pep-0673/) -- Self Type * [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics * [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support for Parsing TOML in the Standard Library * [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal String Type * [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual TypedDict items as required or potentially-missing * [bpo-46752](https://bugs.python.org/issue46752)-- Introduce task groups to asyncio * The Faster Cpython Project <https://github.com/faster-cpython> is already yielding some exciting results. Python 3.11 is up to 10-60% faster than Python 3.10. On average, we measured a 1.22x speedup on the standard benchmark suite. See Faster CPython <https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython>for details. * Hey, **fellow core developer,** if a feature you find important is missing from this list, let me know. The next pre-release of Python 3.11 will be 3.11.0b2, currently scheduled for Monday, 2022-05-30. # More resources * [Online Documentation](https://docs.python.org/3.11/) * [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release Schedule * Report bugs at [https://bugs.python.org](https://bugs.python.org). * [Help fund Python and its community](/psf/donations/). # And now for something completely different The holographic principle is a tenet of string theories and a supposed property of quantum gravity that states that the description of a volume of space can be thought of as encoded on a lower-dimensional boundary to the region—such as a light-like boundary like a gravitational horizon. First proposed by Gerard 't Hooft, it was given a precise string-theory interpretation by Leonard Susskind, who combined his ideas with previous ones of 't Hooft and Charles Thorn.[ Leonard Susskind said, “The three-dimensional world of ordinary experience––the universe filled with galaxies, stars, planets, houses, boulders, and people––is a hologram, an image of reality cited on a distant two-dimensional (2D) surface." As pointed out by Raphael Bousso, Thorn observed in 1978 that string theory admits a lower-dimensional description in which gravity emerges from it in what would now be called a holographic way. The holographic principle was inspired by black hole thermodynamics, which conjectures that the maximal entropy in any region scales with the radius squared, and not cubed as might be expected. In the case of a black hole, the insight was that the informational content of all the objects that have fallen into the hole might be entirely contained in surface fluctuations of the event horizon. The holographic principle resolves the black hole information paradox within the framework of string theory. However, there exist classical solutions to the Einstein equations that allow values of the entropy larger than those allowed by an area law, hence in principle larger than those of a black hole. These are the so-called "Wheeler's bags of gold". The existence of such solutions conflicts with the holographic interpretation, and their effects in a quantum theory of gravity including the holographic principle are not fully understood yet. # We hope you enjoy the new releases! 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/ Regards from chilly London, Your friendly release team, Pablo Galindo Salgado

1 0

Release of Python 3.11 beta 1 is currently blocked
by Pablo Galindo Salgado 06 May '22

06 May '22

Hi everyone, Today we need to start the release of Python 3.11 beta 1. Currently, we have the following blockers: * https://github.com/python/cpython/issues/91162 (was deferred blocker - but all deferred blockers are bumped to release blockers on beta1). * https://github.com/python/cpython/issues/91350 * We have 3 buildbots failing: https://buildbot.python.org/all/#/release_status (some of the failures are due to flaky tests but others look real). Please, if you are involved in the above issues check if they are resolved or if they are not released blockers (notice any semantic change, API change, public data structure change or grammar change must be done before beta 1 is released). I will look at the buildbots later today but if you have some time to investigate, that would help a lot! *I am blocking the main branch so only the release team can merge changes* until these problems are addressed and we can continue with the release. Please, add me as a reviewer to any PR that needs to be merged to address these issues or any other change that *absolutely needs to go into beta 1*. Thanks for your help! Regards from sunny London, Pablo Galindo Salgado

2 2

3.11 feature freeze coming up?
by Ethan Furman 05 May '22

05 May '22

Is this still scheduled for Thursday? -- ~Ethan~

4 4

New triagers: Slateny, Shantanu, CAM Gerlach, Adam Turner, Pradyun Gedam, Ned Batchelder
by Jelle Zijlstra 03 May '22

03 May '22

We have added several new triagers today: - Shantanu (@hauntsaninja), who has been active especially around typing for years and has also made several dozen contributions to CPython ( https://github.com/python/core-workflow/issues/443) - @slateny, who has made a number of thoughtful contributions to CPython docs over the last few months ( https://github.com/python/core-workflow/issues/444) - CAM Gerlach (@CAM-Gerlach), who is a member of the docs community group and also a PEP editor (https://github.com/python/core-workflow/issues/445) - Adam Turner (@AA-Turner), who is a member of the docs community group and also a PEP editor (https://github.com/python/core-workflow/issues/445) - Pradyun Gedam (@pradyunsg), who is a member of the docs community and a maintainer of pip (https://github.com/python/core-workflow/issues/445) - Ned Batchelder (@nedbat), who is a member of the docs community and has contributed more to Python than I could possibly list. I am excited to welcome them all to our community!

4 4

Vote to promote Erlend Aasland
by Pablo Galindo Salgado 23 Apr '22

23 Apr '22

Hi everyone, I have opened a poll to promote Erlend Aasland as a core developer. Please read more and vote here: https://discuss.python.org/t/vote-to-promote-erlend-aasland/15246/2 Thank you! Regards from sunny London, Pablo Galindo Salgado

1 0

Consider adding a Tier 3 to tiered platform support
by Victor Stinner 19 Apr '22

19 Apr '22

Hi, I don't think that the current PEP 11 draft (*) describes correctly the current status of a bunch of platforms which are not "actively" supported. I like to call these plaforms as "best effort support" platforms. I propose considering adding an explicit "Tier 3" to PEP 11. (*) https://github.com/python/peps/pull/2442/ Rust defines its Tier 3 as: "Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work." Tier 3 requirements would be *very weak*: * No buildbot requirement * No assigned core dev needed * Don't revert a change breaking a Tier 3 platform * Don't hold a Python release if a Tier 3 platform is broken Currently, the "All other platforms" section is quite clear: code can be removed anytime: "Code changes to platforms not listed in the above tiers may rejected or removed from the code base *without a deprecation process* if they cause a maintenance burden or obstruct general improvements." The only difference between "Tier 3" and "All other platforms" would be that removing a platform from Tier 3 require a process. I'm not sure if a deprecation is needed. But we have to go through a discussion and someone (SC?) has to decide if it's ok to drop it (remove code). Removing code from Python means in practice that the support *can* still continue, but outside of the Git upstream repository: in a fork instead. For me the main threat of (adding a platform to) Tier 3 is the risk that we might never ever able to drop support for these platforms. PEP 11 would be used by users as a holy document. Maybe we should be clear that Tier 3 is not a strong warranty of long term support, but is just a weak status. For example, put a time bomb: if no developer was available in the last 12 month to fix regressions, drop the platform for Tier 3. -- I'm thinking at these platforms for Tier 3: * AIX 6.4 and newer (has a buildbot) * Android API 24 * FreeBSD * OpenBSD * NetBSD * s390x arch * Solaris (has a buildbot) I would prefer to put FreeBSD and s390x in Tier 3 rather than Tier 2. Users of these platforms and contributors who added support for these platforms are going to be grumpy if we drop such platform without any warning or process. Android support seems to be stale for now. But I would prefer to keep it for now. -- Last year, I proposed to drop immediately Solaris support (remove code): https://mail.python.org/archives/list/python-dev@python.org/thread/VDD7NMED… I read that Solaris was no longer maintained by Oracle. I was wrong. Moreover, many Python users on Solaris started to complained loudly. Not only Solaris is maintained, but it's also under active development. After this thread, Oracle contributed Solaris patches to Python, and set up a buildbot! I suggest thinking twice before adding a platform to Tier 3. Adding it is easy. But there will always be at least *one* very grumpy Python user of this platform who will fight to death to keep his old precious unmaintained broken platform, even if no one else in the world has access to the hardware (no longer sold) and no one is able to fix regressions. -- For now, I would prefer to *not* add the following platforms to Tier 3. Keep them in the gray area of "unsupported" platforms. * DOS * Cygwin * HP-UX * MinGW * VMS (OpenVMS): https://vmspython.org/ Time to time, I merge HP-UX fixes if someone proposes a fix and I have some free cycle to review it. Once, I fixed one Unicode issue specific to HP-UX without having access to HP-UX. It's not the most efficient development method for me: it requires a lot of back and forth exchanges with a developer having access to this platform. I don't want to list HP-UX in Tier 3: I don't have access to HP-UX. -- My notes on platforms supported by Python: https://pythondev.readthedocs.io/platforms.html Victor -- Night gathers, and now my watch begins. It shall not end until my death.

7 13

Please turn on 2FA/MFA support on your GitHub account
by Brett Cannon 18 Apr '22

18 Apr '22

In the SC meeting today we discussed requiring two-factor authentication (aka 2FA/MFA) and came away strongly considering it (but no definitive plans yet). But we did agree that we should send a quick email encouraging everyone to turn on 2FA for their GitHub Accounts regardless of what we decide to do. GitHub's instructions can be found at https://docs.github.com/en/authentication/securing-your-account-with-two-fa… . You can use various apps on your desktop or phone as well as a physical device to manage 2FA. And to be clear, you only need access to your 2FA solution when you log in; it's not a day-to-day action at all (I personally have not used my 2FA since the last time I logged into a new device for the first time or when my GitHub account was attacked and the attackers exhausted my password attempts for the day). For those of you who would prefer to use a hardware device and would like help getting one, we can make a request to the PSF to sponsor devices for those who want them.

4 5