Mailman 3 April 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

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

[IMPORTANT] Preparations for 3.11.0 beta 1
by Pablo Galindo Salgado 14 Apr '22

14 Apr '22

Hi everyone, We have approximately one month until feature freeze and for 3.11.0b1 to be released. I wanted to take this time to share some planning and considerations with you. Please, read carefully these points as they are important. * 3.11.0b1 is scheduled for Friday, 2022-05-06, which is after the PyCon US sprints. As the sprints normally end with a considerable amount of PRs getting merged and the buildbots having a hard time, I may need to move the release before or after to accommodate for this and to prevent the release from going haywire. I will share updates with you as they become available. * The latest alpha releases have been quite challenging. We had a considerable number of release blockers and issues that were raised just a couple of days before the release. Please, check the release blockers on bpo/Github as much as you can and make sure these are resolved before the release date. Any release blockers for 3.11 will block feature freeze. If this happens, the main branch will be blocked and only PRs fixing the blockers will be allowed in that time. * Important!! Please, if you are planning to commit a big chunk of code/ a new big refactor/ a new big feature/ a PEP implementation within this month, please let me know (an email works) so we can be on top of things in the release team and so I can keep an eye on regressions. * Any regression at the time of beta freeze will potentially result in the release team being forced to revert commits and PRs. This means that if we need to revert a new feature or similar it may be delayed to 3.12, so be sure to not commit unstable code as much as is humanly possible. Please, reach out to me if you have any questions, comments or if you want to discuss anything. I want to thank you all for your understanding and collaboration :) Kind regards from rainy London, Your friendly release team

4 6

[RELEASE] The last Python 3.11 alpha (3.11.0a7) is available - Prepare for beta freeze
by Pablo Galindo Salgado 06 Apr '22

06 Apr '22

Brrrrr..... do you feel that? That's the chill of *beta freeze* coming closer. Meanwhile, your friendly CPython release team doesn’t rest and we have prepared a shiny new release for you: Python 3.11.0a7. ************************************************************************************************************************************************************ Dear fellow core developer: This alpha is the last release before feature freeze (Friday, 2022-05-06), so make sure that all new features and PEPs are landed in the master branch before we release the first beta. Please, be specially mindfully to check the CI and the buildbots, maybe even using the test-with-buildbots label in GitHub before merging so the release team don’t need to fix a bunch of reference leaks or platform-specific problems on the first beta release. ************************************************************************************************************************************************************ *Go get the new alpha here:* https://www.python.org/downloads/release/python-3110a7/ **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.0a7 is the last 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 * [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: 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.0b1, currently scheduled for Friday, 2022-05-06. # 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 mathematics, the Dirac delta distribution (δ distribution) is a generalized function or distribution over the real numbers, whose value is zero everywhere except at zero, and whose integral over the entire real line is equal to one. The current understanding of the impulse is as a linear functional that maps every continuous function to its value at zero. The delta function was introduced by physicist Paul Dirac as a tool for the normalization of state vectors. It also has uses in probability theory and signal processing. Its validity was disputed until Laurent Schwartz developed the theory of distributions where it is defined as a linear form acting on functions. Defining this distribution as a "function" as many physicist do is known to be one of the easier ways to annoy mathematicians :) # 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 1

Dependabot actions on my cpython fork
by Paul Moore 02 Apr '22

02 Apr '22

I have a cpython fork on my github account - every so often, dependabot kicks in and runs a whole load of actions, which I don't need. I'm not sure how I can switch these off, short of removing the .github directory (which would mean my fork has diverged from upstream, which I'm therefore reluctant to do). Is there a way of stopping these jobs running? APart from the annoying emails that I just ignore, it's a waste of computing resources for no good reason. Thanks, Paul

2 2