(cross posting to python-committers and python-dev)
I'm happy to announce that the signups for Python Language Summit at PyCon
2020 is now open.
Full details at: https://us.pycon.org/2020/events/languagesummit/
When: Wednesday, April 15, 2020, 9am–4pm (Note, we’re starting 1 hour
earlier than usual!)
Where: David L. Lawrence Convention Center, Pittsburgh, PA, room TBD
Sign up to attend: https://forms.gle/Fg7ayhYTaY75J1r7A (closes Feb 29th,
Sign up to discuss a topic: https://forms.gle/g4BXezH1Vcn7tLds5 (closes Feb
29th, 2020 AoE)
*Who can attend*
We welcome Python core developers, 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
last year’s feedback, our audience prefer more discussions and shorter
To get an idea of past language summits, you can read past years' coverage:
This year's event will be covered by A. Jesse Jiryu Davis again, and will
be posted on PSF's blog.
Some changes to note this year:
1) We plan to start 1 hour earlier (9AM)
2) The room will have U-shaped table layout
Mariatta & Łukasz
The steering council is interested in hearing from *core developers* about
their thoughts around the idea of hiring people to help with the project.
The thinking is if we can pay people to help/assist with the aspects of
development that us volunteers do not enjoy doing or simply lack the time.
This is so we can help maximize our impact as a team of volunteers and
improve Python the best we can. We are also gathering info from folks about
what they (dis)like about the development process at the same time.
The survey can be found at https://forms.gle/p1F9utFiG3PJemaN7. We are
currently restricting this to *only core developers* and one response per
core dev. We would love responses sooner rather than later so we can
analyze the responses in time for PyCon US. Please aim to respond by Feb 15.
I have been mentoring Batuhan Taskaya ("BTaskaya" on BPO, "isidentical" on
the past few months. We have been working closely together on some features
many bugfixes and documentation improvements. He has around 27 commits
merged in CPython
(master branch) and he has been helping to triage and debugging some issues
He has made great progress in learning the CPython workflow, CPython
internals and how to keep
things maintainable and backwards compatible so I decided to give him bug
I will continue mentoring him and I will send him instructions on how to
triage bugs and links to the
relevant sections of the devguide. I ask him to ask me before closing bugs
for the first weeks.
Go get it here: https://www.python.org/downloads/release/python-390a3/ <https://www.python.org/downloads/release/python-390a3/>
This is an early developer preview of Python 3.9
Python 3.9 is still in development. This releasee, 3.9.0a3 is the third of six 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 (2020-05-18) and, if necessary, may be modified or deleted up until the release candidate phase (2020-08-10). 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.9 series, compared to 3.8
Many new features for Python 3.9 are still being planned and written. Among the new major new features and changes so far:
PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence
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;
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>.)
The next pre-release of Python 3.9 will be 3.9.0a4, currently scheduled for 2020-02-17.
We have made even more improvements to the buildbot UI (this time specially
targeted to make easier the life of release managers).
You can read about it on discourse:
(The post contains images and reads better there).
Kind regards from cloudy London,
Pablo Galindo Salgado
** Note: This message contains images and is better visualized in
## Testing PRs with buildbots :robot:
After some work (and updating the buildbot server to Python3.8), I am happy
to announce that after some work, is now possible to test a Pull Request
with the buildbot fleet on demand by just adding a simple label (:hammer:
When you add this label to an existing Pull Request:
* A build will be immediately triggered in a selected subset of the stable
buildbots. Every buildbot will report to the PR the build status (like
Travis, Azure Pipelines...etc).
* As long as the label is in the Pull Request *every new commit to the pr
will be tested with the buildbots* in the same way that Travis or Azure
Pipelines test every commit that is pushed to the PR.
* Clicking the "Details" link in the GitHub status will bring you to the
builder page if you want to read logs or see the build live.
* The checks are *not required* to merge the PR. This means that if you
decide so, you can proceed and merge the PR even if a buildbot is failing
(for example, if the failure is unrelated to the PR).
In the [buildbot page](https://buildbot.python.org/all/#/builders) you can
distinguish all the builders that are building PRs by a new `Pull Request`
## When to use the new label :man_student:
Using the buildbots before merging will be especially useful in the
* You are reviewing a big C PR and you want to make sure that there are no
refleaks by using the refleak-detection builders. These builders take more
time but will tell you if the PR has some sneaky reference leaks.
* You want to make sure that the PR builds on all platforms. We have a big
collection of platforms (various versions of Windows, macOS, Linux distros)
and configurations (debug, non-debug, PGO/LTO, LTO, clang sanitizers...)
and if you want to make sure that a PR that you suspect may behave
differently by platform (like adding new POSIX functions) will not break
later, is a good practice to test with the buildbots first.
* Because you don't want us to suffer afterwards if your PR fails on some
obscure platform ;)
* Each individual builder has a limited amount of PRs that can be tested
simultaneously (depends on the builder) so it may take a while to start
building your PR. So please, be patient! You can check the status of all
builders in the [buildbot page](https://buildbot.python.org/all/#/builders)
* Remember that the buildbots are donated machines, so remember to be a
good citizen and double-check the code of the PR before adding the label.
This new addition should allow you to gain confidence when merging a PR
with minimum impact in your existing workflow and effort. If you have any
feedback or feature request, go ahead and tell us :)
Kind regards from rainy London,
Pablo Galindo Salgado
Below is an update from the Steering Council. It covers November and
The update has been added to the Steering Council repo:
to README as well).
# Steering Council Community Update for November - December 2019
## November recap:
- Steering Council assigned one another tasks to check-in on and clean up
29 open PEPs in November (Nov 5 and Nov 12 meetings). See [PEP repo](
https://github.com/python/peps/) for details.
- Steering Council decided that going forward, only one person will need to
approve the minutes and the group will try to rotate that responsibility.
Additionally, to keep meetings efficient we will:
- 1. have a person responsible for the agenda to make sure the agenda
is accurate and timed appropriately
- 2. have a person run the actual meeting to make sure we stay on
topic and cut discussions when topics go over time.
- Steering Council discussed ideas on how to lower the count of PRs. It was
decided that Brett would start a discussion on Discourse with the idea to
close enhancement PRs. This has been done [here](
At a later time, it was decided the idea would be shut down since many
folks did not approve.
- Steering Council discussed how a hiring plan can coincide with the Vision
Deck and how it would work with sponsor/corporate collaborations. The
Vision Deck is an overview document the Steering Council is drafting, which
will help develop Python's roadmap for the next 5 years. Goal is to have
the Vision Deck complete by PyCon 2020.
- Steering Council had a brief discussion about encouraging more candidates
to run for the next steering council and that everyone would work on
raising awareness for this.
## December recap:
- The Steering Council reviewed [PEP 584](
https://www.python.org/dev/peps/pep-0584/) (“Add + and += operators to the
built-in dict class”) and decided that Guido would let the PEP authors know
| and |= was preferred and that the PEP needed some editing. [This was
At a later time it was decided that Guido will be BDFL-Delegate.
- The Steering Council decided it would meet after the 2020 Steering
Council vote ended. The Steering Council will meet December 10 and December
17th. The hand-off meeting will happen the first week of January. Ewa will
send out a Doodle for the first full week of January once the new Steering
Council members are known. It was decided that on January 8th, 2020 the
Steering Council will have a hand-off meeting between the 2019 team and
- Steering Council decided that we would send out ballots to Marc-Andre
Lemburg, Alex Martelli, and Kurt B. Kaiser. [Brett responded to thread](
noting this decision and future plans for [PEP 13](
- Steering Council discussed [PEP 611](
https://www.python.org/dev/peps/pep-0611/). Barry [emailed the python-dev@
with the outcome of the discussion.
- Steering Council discussed PyPI’s typosquatting issues.
- Group discussed the status of the GitHub migration plan. Ewa drafted a
job description for the Project Manager role to help with the GitHub
migration for the Dec 17th SC meeting. The Steering Council reviewed it and
Ewa scheduled a call with the GitHub team for late January for next steps.
- Steering Council decided to keep Zulip since the Packaging-wg plans on
using it. We will re-evaluate usage next year. Guido informed the
[posted an announcement](
*As a non-profit organization, the PSF depends on sponsorships and
donations to support the Python community. Check out our Annual Impact
Report for more details: https://www.python.org/psf/annual-report/2019/
*Please contribute to PSF; we can't continue our work without your
I just wanted to say congratulations to everyone for reaching this point! I know it has been a long time coming and quite the struggle sometimes over the past decade, but we reached our (extended) end for Python 2 without having the entire community and language collapse as some had predicted would occur when we started our journey to making Py3K a reality.
Hopefully everyone can enjoy watching the 2.7 branch sit there as it pines for the fjords and rests until April when we all can watch Benjamin click the final button to release Python 2.7.18 at PyCon US and send Python 2 off as it ceases to be (at least from our perspective 😉).