Mailman 3 October 2019 - python-committers

The PSF's new Code of Conduct and how it applies to Python's development
by Brett Cannon Oct. 2, 2019

Oct. 2, 2019

[this is being emailed out to python-committer and python-dev separately, so apologies for those who get a duplicate email] The steering council wanted to let everyone know that the PSF released a new Code of Conduct which was announced at https://pyfound.blogspot.com/2019/09/the-python-software-foundation-has_24.… and that it applies to Python's development. Specifically, this new Code of Conduct lists Python's development spaces and those participating in those spaces as being under the CoC (we were implicitly under the old CoC on PSF-sponsored and run infrastructure, but now it's explicitly called out). So that means python-committers, python-dev, python-ideas, everything on GitHub, discuss.python.org, core dev sprints, PSF-sponsored conferences, etc. all fall under this CoC. The steering council wanted to make sure people were aware of this new Code of Conduct so no one was caught off-guard and to make sure people were aware that it did apply to all of us. The steering council also supports this Code of Conduct. One other thing the steering council wanted to point out is that we believe CoC violations should be reported directly to the Conduct WG as outlined at https://www.python.org/psf/conduct/reporting/. The thinking is that since we all know each other on the development team there's a good chance of a conflict of interest if reports were to go to the steering council, and so it's simpler to just advise people go straight to the Conduct WG (Carol and I will recuse ourselves as appropriate since we are both on the Conduct WG). I will also say that people have come to me personally in the past and asked if something was a CoC violation, and going forward my answer will be "report it to the Conduct WG and let them make that decision". Same goes for incidents where people believe something is a CoC violation and they want to report it to someone: let the Conduct WG know (which I have already started telling people who come to me with CoC concerns).

1 0

[RELEASE] Python 3.7.5rc1 is now available for testing
by Ned Deily Oct. 1, 2019

Oct. 1, 2019

Python 3.7.5rc1 is now available for testing. 3.7.5rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. Assuming no critical problems are found prior to 2019-10-14, no code changes are planned between now and the final release. This release candidate is intended to give you the opportunity to test the new security and bug fixes in 3.7.5. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that this is a preview release and, thus, its use is not recommended for production environments. You can find the release files, a link to the changelog, and more information here: https://www.python.org/downloads/release/python-375rc1/ -- Ned Deily nad(a)python.org -- []

1 0

[RELEASE] Python 3.8.0rc1 is now available
by Łukasz Langa Oct. 1, 2019

Oct. 1, 2019

Python 3.8.0 is almost ready. After a rather tumultuous few days, we are very happy to announce the availability of the release candidate: https://www.python.org/downloads/release/python-380rc1/ <https://www.python.org/downloads/release/python-380rc1/> This release, 3.8.0rc1, is the final planned release preview. Assuming no critical problems are found prior to 2019-10-14, the scheduled release date for 3.8.0, no code changes are planned between this release candidate and the final release. Please keep in mind that this is not the gold release yet and as such its use is not recommended for production environments. Major new features of the 3.8 series, compared to 3.7 Some of the new major new features and changes in Python 3.8 are: PEP 572 <https://www.python.org/dev/peps/pep-0572/>, Assignment expressions PEP 570 <https://www.python.org/dev/peps/pep-0570/>, Positional-only arguments PEP 587 <https://www.python.org/dev/peps/pep-0587/>, Python Initialization Configuration (improved embedding) PEP 590 <https://www.python.org/dev/peps/pep-0590/>, Vectorcall: a fast calling protocol for CPython PEP 578 <https://www.python.org/dev/peps/pep-0578>, Runtime audit hooks PEP 574 <https://www.python.org/dev/peps/pep-0574>, Pickle protocol 5 with out-of-band data Typing-related: PEP 591 <https://www.python.org/dev/peps/pep-0591> (Final qualifier), PEP 586 <https://www.python.org/dev/peps/pep-0586> (Literal types), and PEP 589 <https://www.python.org/dev/peps/pep-0589> (TypedDict) Parallel filesystem cache for compiled bytecode Debug builds share ABI as release builds f-strings support a handy = specifier for debugging continue is now legal in finally: blocks on Windows, the default asyncio event loop is now ProactorEventLoop on macOS, the spawn start method is now used by default in multiprocessing multiprocessing can now use shared memory segments to avoid pickling costs between processes typed_ast is merged back to CPython LOAD_GLOBAL is now 40% faster pickle now uses Protocol 4 by default, improving performance (Hey, fellow core developer, if a feature you find important is missing from this list, let Łukasz know <mailto:lukasz@python.org>.) Call to action: focus on the docs now Are all your changes properly documented? Did you notice other changes you know of to have insufficient documentation? Can you help with the “What’s New <https://docs.python.org/3.8/whatsnew/3.8.html>” document? - Ł

1 0

Currently working on the release of Python 3.8.0rc1
by Łukasz Langa Oct. 1, 2019

Oct. 1, 2019

Team, amazing job on getting us back on track over the weekend. Thank you All release blockers and deferred release blockers solved. And there was relatively little additional activity on the branch -- as expected at this point! Thank you for this, it will help get the release candidate out on time. I'm working on cutting RC1 today Hopefully all sanity checks, as well as building the source tarball and the binary installers for macOS and Windows will all work out fine and we'll be seeing RC1 out tonight. RC2 and the date of 3.8.0 gold If we manage to avoid the need for RC2, we will be able to release 3.8.0 on October 14th. If we need an RC2, that will slip by a week. I hope we won't. Ideally RC1 should be identical codewise to 3.8.0. To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.) Note I didn't say I forbid any activity. I have no power over you, actually. More importantly though, I trust your judgement if you assess some bug is bad enough the fix absolutely has to get into 3.8.0. Moreover, I specifically said source-related activity because... 3.8.0 is important. To some users it will be the first and the last release in the 3.8 series they will see. We need you to focus on the docs now Are all your changes properly documented? Did you notice other changes you know of to have insufficient documentation? Can you help with the "What's New" document? anxiously configure-&&-makingly y'rs - Ł

5 7