The following message was sent to a core developer. This message was thoughtfully and respectfully sent by the Steering Council as a serious reminder that the privilege to serve as a core developer comes with the responsibility to act thoughtfully.
Based on Code of Conduct violations in your recent mailing list posts, and under the recommendation of the Code of Conduct Working Group, the Python Steering Council has voted to issue a three-month corrective action to you for Core Python development.
This corrective action bans you from all Core Development privileges including commit rights, issue tracker privileges, and participation in all core development communication spaces including mailing lists, Discourse, and Zulip channels. This corrective action will be in effect for three months. At the end of the three month period, these privileges will be automatically reinstated.
The Python Code of Conduct workgroup reviewed the conduct reports and recommended that corrective action was necessary for the violations. The Python Steering Council finds these violations to be serious breaches of civility and expected core development conduct.
Please consider this corrective action as a serious reminder that Python core development is a privilege. This privilege to serve as a core developer comes with the responsibility to act thoughtfully and reflect on how hostile communications are harmful to other members of the community. We trust that you will respect the temporary loss of privileges and the seriousness of this action.
Python Steering Council
My two cents: I think this should be a little more liberal. At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, additional tests, algorithmic improvements, and better docs. For many of the devs (and users), the first time we get to exercise and interact with some of the new features is during the beta — that is our chance to improve and stabilize it before it goes out the door. If a new API proves awkward in some way, the time to find out and improve it is during the beta. Ideally, we would like both the API and implementation to mature a bit before the release (first draft != final copy). A release candidate is different — that is close to an across-the-board freeze. Once the release happens, bug fixes and documentation tweaks will continue to be checked in for the next micro-release.
Side note: One problem we have is that so few people actually exercise the beta and give useful feedback. To me, the chief value of a public beta is that people get to try it out before everything is set it stone. And reason for having multiple betas is so that we can iterate. If not, perhaps we should just have a single beta, frozen except for bugfixes.
[This has been sent to python-committers, python-dev, and python-ideas]
Recently, a series of discussions on this mailing list resulted in behavior
that did not live up to the standards of the Python Community. The PSF
Board of Directors, Python Steering Council, and the PSF Conduct Working
Group would like to remind this community that our shared goal is to
advance the Python language while simultaneously building a diverse,
inclusive, and welcoming Python community. While the community has made
progress in recent years, this discussion made it clear to many of us that
we still have room to grow.
At the request of the PSF Board, the Steering Council, and members of the
community, the PSF Conduct WG met to discuss these recent events and
recommend action. As a result, warnings will be given to several members of
the Python Community, and the Steering Council will be taking further
Especially during passionate discussions like these, we'd like to ask that
all Pythonistas focus on being welcoming and respectful, and that we all
try to act in the best spirit of the Python Community.
Python Steering Council
PSF Board of Directors
PSF Conduct WG
This is a combined release of Python 3.8.5 and 3.9.0b5. Both are significant but for different reasons. Let’s dig in!
Security content in 3.8.5
We decided to release 3.8.5 ahead of schedule due to a number of security-related fixes. All details can be found in the change log <https://docs.python.org/release/3.8.5/whatsnew/changelog.html#changelog> but the gist is:
CVE-2019-20907 <https://bugs.python.org/issue39017>: infinite loop in a maliciously created .tar file
BPO-41288 <https://bugs.python.org/issue41288>: segmentation fault during unpickling of objects using a crafted NEWOBJ_EX opcode
BPO-39603 <https://bugs.python.org/issue39603>: HTTP headers could be injected through a maliciously crafter method parameter in http.client
the original fix for CVE-2020-15801 caused a regression in 3.8.4 (see: BPO-41304 <https://bugs.python.org/issue41304>)
A small number of other urgent regression fixes and quality-of-life improvements are also present in the release. Get the release here:
Maintenance releases for the 3.8 series will continue at the regular bi-monthly calendar, with 3.8.6 planned for mid-September 2020.
The last beta of Python 3.9.0 now also available
Python 3.9 is still in development. This release, 3.9.0b5, is the last of five 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. You can get 3.9.0b5 here:
The next pre-release, the first release candidate of Python 3.9.0, will be 3.9.0rc1. It is currently scheduled for 2020-08-10.
Call to action
We strongly encourage maintainers of third-party Python projects to test with 3.9 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 (2020-08-10). Our goal is have no ABI changes after beta 5 and as few code changes as possible after 3.9.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.9 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.
A reminder for core developers
To help make Python 3.9.0 the best possible release, our Development Cycle <https://devguide.python.org/devcycle/#release-candidate-rc> section of the Python Developer’s Guide documents that:
A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point.
You cannot skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, everything requires peer review from a core developer.
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 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 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/>.
(Hey, fellow core developer, if a feature you find important is missing from this list, let Łukasz know <mailto:firstname.lastname@example.org>.)
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.
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>
there are 3 security-related fixes in the 3.8 branch post 3.8.4, one with a CVE, another with a pending CVE if I understood Steve correctly. I'd like to release a hotfix 3.8.5 on Monday.
Since this is a special security-focused release, it will be essentially 3.8.4 + those three changes cherry-picked. That gives us enough confidence about the release that we can skip a release candidate for it.
If you have any other security-related changes you think belong in 3.8, please merge them before Monday 8am CEST.