Mailman 3 March 2022 - python-committers

Proposed tiered platform support
by Brett Cannon 10 Jun '22

10 Jun '22

I brought this up on python-dev at https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP… , and the feedback seemed supportive. As such, I am bringing a draft of what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders for people to help me fill in to see how this will look overall. For any platform(s) you support, please reply with any relevant details that should be added to the relevant tables below. Once I have these details I will loop back with the proposed update to PEP 11 and make sure everyone is still on board with the proposal. ===== Tiers ===== Tier 1 ====== - `Test suite failures < https://github.com/python/cpython/actions/workflows/build.yml?query=branch%…>`__ block releases. - Changes which would break the ``main`` branch are not allowed to be merged; any breakage may be reverted immediately. - All core developers are responsible to keep these platforms working. - Promotion of this tier requires consensus/SC approval. =================== ===== Target Triple Notes =================== ===== i686-windows-msvc x86_64-windows-msvc x86_64-apple-darwin macOS 11 x86_64-linux-gnu glibc 2.31 |ubuntu-20_01|_ =================== ===== .. [ubuntu-20_01] https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4 Tier 2 ====== - Must have a stable buildbot. - At least **two** core developers are signed up to support the platform. - Changes which break any of these platforms are to be reverted within 24 hours. - Failures of these platforms block a release. - Promotion of this tier requires consensus/SC approval. ====================== ========================== ============================================== ======== Target Triple Notes Buildbot Contacts ====================== ========================== ============================================== ======== aarch64-apple-darwin XXX https://buildbot.python.org/all/#/builders/725 XXX aarch64-linux-gnu glibc XXX [fedora-stable]_ https://buildbot.python.org/all/#/builders/125 XXX glibc 2.28 [RHEL8]_ https://buildbot.python.org/all/#/builders/529 XXX aarch64-windows-msvc XXX https://buildbot.python.org/all/#/builders/729 XXX powerpc64-linux-gnu glibc XXX https://buildbot.python.org/all/#/builders/237 XXX powerpcle-linux-gnu glibc XXX https://buildbot.python.org/all/#/builders/90 XXX s309x-linux-gnu glibc XXX https://buildbot.python.org/all/#/builders/223 XXX glibc 2.28 [RHEL8]_ https://buildbot.python.org/all/#/builders/509 XXX glibc 2.17 [RHEL7]_ https://buildbot.python.org/all/#/builders/179 XXX x86_64-linux-gnu glibc 2.17 [RHEL7]_ https://buildbot.python.org/all/#/builders/15 XXX x86_64-unknown-freebsd XXX https://buildbot.python.org/all/#/builders/172 XXX ====================== ========================== ============================================== ======== .. [fedora-stable] XXX .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8 .. [RHEL7] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… Tier 3 ====== - Must have a stable buildbot. - Code may be checked into ``main`` for the platform. - At least **one** core developer is signed up to support the platform. - Test failures do **not** block releases. - Promotion to this tier is self-service. ========================= ========================== ============================================== ======== Target Triple Notes Buildbot Contacts ========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX Brett Cannon, Christian Heimes wasm32-unknown-wasi XXX XXX Brett Cannon, Christian Heimes ========================= ========================== ============================================== ======== All other platforms =================== - Only code which either supports a higher-tier platform or is a general improvement may be checked in.

13 48

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

Python Language Summit at PyCon 2022 in Salt Lake City
by Mariatta 24 Mar '22

24 Mar '22

We're excited to announce that the signups for Python Language Summit at PyCon 2022 are now open. Full details at: https://us.pycon.org/2022/events/language-summit/ After two years of virtual/online summit, we will be returning to in-person format. We will be following the health and safety guidelines at PyCon US: https://us.pycon.org/2022/attend/health-safety-guidelines/ *TL;DR* When: Wednesday, April 27, 2022 Where: Salt Palace Convention Center, room TBD Sign up to attend: https://forms.gle/CS8B6wJdcaN3rtWV8 <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) *Who can attend* We welcome Python core developers and triage team members, active core contributors to Python and alternative Python implementations, and anyone else who has a topic to discuss with core developers. *Who can propose a discussion topic* If you have discussion items; seeking consensus; awaiting decision on a PEP; needing help with your core dev work; or have specific questions that need answers from core developers, please submit a proposal. According to feedback, our audience prefers more discussions and shorter talks. In your proposal, please include: - why is this topic relevant to the core developers - what is needed from core developers out of this topic This year's event will be covered by Alex Waygood. Detailed summary of the event will be published at The PSF's Blog. *Is this event recorded? Can I watch the livestream?* No, there will be no recording and no livestream available. If you'd like to participate in discussions, please sign up to attend. If you'd like to listen in, please wait for Alex's blog posts after the summit. Thank you, Mariatta, Łukasz, & Senthil

1 2

[RELEASE] Python 3.10.4 and 3.9.12 are now available out of schedule
by Łukasz Langa 24 Mar '22

24 Mar '22

Did anybody say cursed releases <https://discuss.python.org/t/python-3-10-3-3-9-11-3-8-13-and-3-7-13-are-now…>? 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 <https://access.redhat.com/support/policy/updates/errata>, it’s still used in production workloads. Some of those rely on Python 3.9 and/or 3.10. In particular, our own manylinux2010 <https://github.com/pypa/manylinux/tree/manylinux2010_x86_64_centos6_no_vsys…> 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 <https://peps.python.org/pep-0599/> and PEP 600 <https://peps.python.org/pep-0600/> 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 <https://www.python.org/downloads/release/python-3104> Get 3.9.12 here: Python Release 3.9.12 | Python.org <https://www.python.org/downloads/release/python-3912> 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. <https://discuss.python.org/t/python-3-10-4-and-3-9-12-are-now-available-out…>We hope you enjoy the new releases Your friendly release team, Łukasz Langa @ambv <https://discuss.python.org/u/ambv> Pablo Galindo Salgado @pablogsal <https://discuss.python.org/u/pablogsal> Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>

1 0

Requiring PEPs to add/remove modules in the stdlib (and dropping the concept of "provisional")
by Brett Cannon 23 Mar '22

23 Mar '22

I had kicked off a discussion a while back at https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to… about how to manage the stdlib (this has nothing to with *what* the stdlib is and thus what belongs in it). It finally bubbled up in the SC agenda and after discussing things we have three proposals: 1. Update PEP 2 to say a PEP is necessary to add a module to the stdlib 2. Update PEP 4 to say that a PEP is necessary to deprecate/remove a module 3. Mark PEP 411 as obsolete and thus dropping the idea of provisional modules The PEP requirements are because the stdlib is important to manage appropriately and since it's a shared resource it should be something we all discuss. The PEP process seems like a good mechanism for both keeping what we bring in under control while also making sure people don't break people's code needlessly with removals. The dropping of the concept of provisional modules is from simply having not seen any true benefit that could have been had in other ways (e.g. typing, asyncio, importlib.metadata). In pretty much all cases the APIs could have evolved publicly first and then been brought into the stdlib once stable (if at all), so the concept of "provisional" just doesn't seem worth keeping around. We wanted to see if there was consensus around any of these ideas, hence this email. 🙂

7 9

[RELEASE] Python 3.10.3, 3.9.11, 3.8.13, and 3.7.13 are now available with security content
by Łukasz Langa 16 Mar '22

16 Mar '22

Welcome again to the exciting world of releasing new Python versions! Last time around I was complaining about cursed releases <https://discuss.python.org/t/python-3-10-2-3-9-10-and-3-11-0a4-are-now-avai…>. This time around I could complain about security content galore and how one of them <https://mta.openssl.org/pipermail/openssl-announce/2022-March/000216.html> ruined my ingenious idea to release Python on Pi Day and call it Py Day <https://discuss.python.org/t/py-day-is-coming-a-joint-security-release-spre…>. Well, you can’t have everything in life. Or at least not everything at once. And yet it seems this time around we’ve got a lot of security fixes all at once. Just look at this list: 15 (sic!) CVEs: libexpat upgraded from 2.4.1 to 2.4.7 (BPO-46794 <https://bugs.python.org/issue46794>, BPO-46932 <https://bugs.python.org/issue46932>, BPO-46811 <https://bugs.python.org/issue46811>, BPO-46784 <https://bugs.python.org/issue46784>, BPO-46400 <https://bugs.python.org/issue46400>) CVE-2022-0778: OpenSSL upgraded from 1.1.1l to 1.1.1n in macOS and Windows installers (BPO-47024 <https://bugs.python.org/issue47024>) CVE-2016-3189, CVE-2019-12900: bzip2 upgraded from 1.0.6 to 1.0.8 in Windows installers (BPO-44549 <https://bugs.python.org/issue44549>) CVE-2022-26488: Windows installer now ensures the correct path is being repaired when “Add to PATH” is used (BPO-46948 <https://bugs.python.org/issue46948>) CVE-2021-28363: bundled pip upgraded from 21.2.4 to 22.0.4 (BPO-46985 <https://bugs.python.org/issue46985>) authorization bypass fixed in urllib.request (BPO-46756 <https://bugs.python.org/issue46756>) REDoS avoided in importlib.metadata (BPO-46474 <https://bugs.python.org/issue46474>) SQLite upgraded from 3.36.0 to 3.37.2 in macOS and Windows installers (BPO-45925 <https://bugs.python.org/issue45925>) <https://discuss.python.org/t/python-3-10-3-3-9-11-3-8-13-and-3-7-13-are-now…>Python 3.10.3 Get it here: https://www.python.org/downloads/release/python-3103/ <https://www.python.org/downloads/release/python-3103/> Python 3.10.3 is the third maintenance release of the newest version of the Python programming language, which contains many new features and optimizations. We recommend it over the other releases listed below. This is a large bugfix release with 220 commits since 3.10.2. Just look at the change log <https://docs.python.org/release/3.10.3/whatsnew/changelog.html>! The next maintenance release of Python 3.10 is planned for early June. <https://discuss.python.org/t/python-3-10-3-3-9-11-3-8-13-and-3-7-13-are-now…>Python 3.9.11 Get it here: https://www.python.org/downloads/release/python-3911/ <https://www.python.org/downloads/release/python-3911/> This is the penultimate planned full bugfix release of Python 3.9. In mid-May, we’ll be releasing the last one, after which the 3.9 series will enter its security-only fixes period. More details in PEP 596 <https://www.python.org/dev/peps/pep-0596/>. Python 3.9 is the first Python version since 2.7 to have a regular bugfix release larger than “.10”. It’s also still a significant release at 163 commits since 3.9.10. That’s in fact 30+ commits more than between 3.9.9 and 3.9.10. The change log <https://docs.python.org/release/3.9.11/whatsnew/changelog.html> isn’t as long as the 3.10.3 one but it’s still pretty extensive! As a reminder, on macOS, the default installer is now the new universal2 variant. It’s compatible with Mac OS X 10.9 and newer, including macOS 11 Big Sur and macOS 12 Monterey. Python installed with this variant will work natively on Apple Silicon processors. <https://discuss.python.org/t/python-3-10-3-3-9-11-3-8-13-and-3-7-13-are-now…>Python 3.8.13 Get it here: https://www.python.org/downloads/release/python-3813/ <https://www.python.org/downloads/release/python-3813/> Changes <https://docs.python.org/release/3.8.13/whatsnew/changelog.html> here are almost exclusively security-only as the life cycle of Python versions prescribes. You might have noticed there is a small number of regular bug fixes nonetheless. This is because without those we wouldn’t be able to continue running the full test suite for the 3.8 branch. This in turn could hide regressions in future security fixes. <https://discuss.python.org/t/python-3-10-3-3-9-11-3-8-13-and-3-7-13-are-now…>Python 3.7.13 Get it here: https://www.python.org/downloads/release/python-3713/ <https://www.python.org/downloads/release/python-3713/> Just like 3.8, Python 3.7 is in its security-only fixes period. In turn, the changes in 3.7.13 <https://docs.python.org/release/3.7.13/whatsnew/changelog.html> look almost identical to the ones in 3.8.13. Python 3.7 will continue to receive source-only releases until June 2023. <https://discuss.python.org/t/python-3-10-3-3-9-11-3-8-13-and-3-7-13-are-now…>We hope you enjoy the new releases Your friendly release team, Łukasz Langa @ambv <https://discuss.python.org/u/ambv> Pablo Galindo Salgado @pablogsal <https://discuss.python.org/u/pablogsal> Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>

1 0

Candidates for next release manager
by Pablo Galindo Salgado 15 Mar '22

15 Mar '22

Hi, As Python 3.11.0 beta 1 approaches, we need to start considering the new release manager. *If you are interested in being the release manager for Python 3.12 (and potentially Python 3.13* *if you wish), please reach out to me.* Ok, but what does a release manager do? * The release manager is in charge of doing all the Python releases associated with the versions that they are in charge of. This includes normally 7 alphas, 4 betas, 2 release candidates, final versions, bugfix releases every 2 months for approximately 18 months and any source-only security releases for 5 years after the release of the final version. *This means that this is a commitment of at least 5 years. *To get an idea of what's involved in a release, check PEP 101 <https://peps.python.org/pep-0101/>. * The release manager is in charge of ensuring that the releases are stable. This means continuous monitoring of the buildbots, shepherding some issues and release blockers, performance degradation and many other aspects. This means that is very important for the release manager to keep track of the technical details of the development of the versions they are in charge of. * The release manager needs to ensure that release blockers are identified and fixed before the releases are done. This includes coordinating core developers to fix the release blockers or revert the relevant changes in cases fixes are not available in a reasonable amount of time. * The release manager needs to author and maintain the release schedule PEPs. Check PEP 664 <https://peps.python.org/pep-0664/> as an example. * The release manager needs to ensure the "What's new" document for the releases they are in charge of is complete and properly reflects all changes, highlights and additions that are included in the release. This could be done personally by the release manager or coordinated by them. If you have any questions, please reach out to me (or any other release manager if you want) and we will be happy to answer them :) Regards from sunny London, Pablo Galindo Salgado

1 0

[RELEASE] Python 3.11.0a6 is available
by Pablo Galindo Salgado 07 Mar '22

07 Mar '22

There are no easy releases these days! :sweat: After a week of delay due to several release blockers, buildbot problems and pandemic-related difficulties here is 3.11.0a6 for you to test. https://www.python.org/downloads/release/python-3110a6/ **This is an early developer preview of Python 3.11** # Major new features of the 3.11 series, compared to 3.10 Python 3.11 is still in development. This release, 3.11.0a6 is the sixth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2022-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2022-08-01). Please keep in mind that this is a preview release and its use is **not** recommended for production environments. 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 * The [Faster Cpython Project](https://github.com/faster-cpython) is already yielding some exciting results: this version of CPython 3.11 is ~12% faster on the geometric mean of the [PyPerformance benchmarks]( speed.python.org), compared to 3.10.0. * 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.0a7, currently scheduled for Tuesday, 2022-04-05. # 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 In astrophysics and nuclear physics, nuclear pasta is a theoretical type of degenerate matter that is postulated to exist within the crusts of neutron stars. If it does in fact exist, nuclear pasta is the strongest material in the universe. Between the surface of a neutron star and the quark-gluon plasma at the core, at matter densities of 1014 g/cm3, nuclear attraction and Coulomb repulsion forces are of similar magnitude. The competition between the forces leads to the formation of a variety of complex structures assembled from neutrons and protons. Astrophysicists call these types of structures nuclear pasta because the geometry of the structures resembles various types of pasta. There are several phases of evolution (I swear these names are real), including the gnocchi phase, the spaghetti phase, the lasagna phase, the bucatini phase and the Swiss cheese phase. # We hope you enjoy those 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. Your friendly release team, Pablo Galindo @pablogsal Ned Deily @nad Steve Dower @steve.dower

1 0

Python 3.11.0a6 is blocked
by Pablo Galindo Salgado 03 Mar '22

03 Mar '22

Hi everyone, Unfortunately, we have some issues marked as release blockers that are holding the 3.11.0a6 release. Some of these issues have been solved but we still have a couple of them. Hopefully, we will solve these soon and I will proceed with the release. Thanks for your understanding. Regards from sunny Salamanca, Pablo Galindo Salgado

2 3