At the ongoing PyCon 2019 event, Python Steering Council shed some light on the recent changes in the Python governance structure and what these changes mean for the larger Python community.
PyCon 2019 is the biggest gathering of developers and experts who work with the Python programming language. It is scheduled from May 1 to May 9 and is happening at Cleveland, Ohio. Backed by Python Software Foundation (PSF), this event hosts various tutorials, talks, summits, as well as a job fair.
The Python Steering Council
After a two week nomination period (January 7 to January 20), which was followed by a two week voting period (January 21 to February 4), five members were selected for the Python Steering Council:
- Guido van Rossum, the brilliant mind behind the Python programming language and the former Python BDFL (Benevolent Dictator for Life).
- Barry Warsaw, a Senior Staff Software Engineer at LinkedIn, and also the lead maintainer for Jython.
- Brett Cannon, a Principal Software Engineering Manager at Microsoft and a Python core developer for over 15 years.
- Carol Willing, a Research Software Engineer for Project Jupyter, Python core developer, and PSF Fellow
- Nick Coghlan, a CPython Core developer for Python Software Foundation
On why Guido van Rossum stepped down from being BDFL
Since the dawn of the Python era, Guido van Rossum served as its Benevolent Dictator for Life (BDFL). It is a designation given to open-source software development leaders who have the final say in any kind of argument within the community. Guido stepped down from this designation last year in July and became a part of the Steering Council.
Being a BDFL he was responsible for going through all the Python-ideas that might become controversial. Eventually, it ended up becoming his responsibility to take the final decision for PEPs which has already been discussed among the people with greater domain knowledge and expertise. After playing such a key authoritative role for nearly 30 years, Guido started experiencing, what is really common nowadays in the tech industry, the burnout syndrome. So, he finally took the right step of stepping down from his role as a BDFL and urging the core python core developers to discuss and decide amongst themselves the kind of governance structure they want for the community going forward. After months of intense research and debate, the team arrived at the decision of distributing these responsibilities among the five elected steering council members who have earned the trust of the Python community.
He adds, “…that’s pretty stressful and so I’m very glad that responsibility is now distributed over five experts who have more trust of the community because they’ve actually been voted in rather than just becoming the leader by happenstance.”
Sharing his feelings about stepping down from the BDFL role, he said, “…when your kid goes off to college some of you may have experience with that I will soon have that experience. You’re no longer directly involved in their lives maybe but you never stop worrying and that’s how I feel about Python at the moment and that’s why I nominated myself for the steering committee.”
Changes in the PEP process with the new governance model
The purpose behind Python Enhancement Proposals (PEPs) was to take away the burden from Guido of going through each and every email to understand what the proposal was about. He just needed to read one document listing all the pros and cons related to the proposal and then make a decision. This entire decision-making process was documented within the PEPs. With the growing Python community, this process became quite unattainable for Guido as all the decisions funneled through him.
So, that is why the idea of BDFL delegate came up: an expert who will take care of the decision-making for a particular feature. However, earlier employing a BDFL delegate was the last resort and it was done for those aspects of the ecosystem that Guido didn’t want to get involved in. With the new governance model, this has become the first resort.
Barry Warsaw, said, “…we don’t want to make those decisions if there are people in the community who are better equipped to do that. That’s what we want to do, we want to allow other people to become engaged with shaping where Python is going to go in the next 25 years.”
Hiring a Project Manager to help transition from Python 2 to 3
The countdown for Python 2 has started and it will not be maintained past 2019. The steering council has plans for hiring a Project Manager to help them better manage the sunset of Python 2. The PM will also have the responsibility of looking into minor details as well, for instance, in the documentation, there is mention of Python 2 and 3. These instances will need to be updated, as from 2020 we will only have Python and eventually developers will not have to care about the major numbers.
For the systems that haven’t migrated, there will be commercial vendors offering support beyond 2020. There will also be options for business-critical systems, but it will take time, shared Willing. One of the responsibilities that the PM role will take care of will be looking into the various best practices that other companies have followed for the migration and help others to easily migrate.
Willing said, “Back in a couple of years, Instagram did a great keynote about how they were moving things from 2 to 3. I think one of the things that we want a PM to help us in this transition is to really take those best practices that we’re learning from large companies who have found the business case to transition to make it easier.”
Status of CPython issue tracking migration from Roundup to GitHub
All PSF’s projects including CPython have moved to GitHub, but the issue tracking for CPython is still done through Roundup. Marieta Wijaya, a Platform Engineer at Zapier and a core python developer, wrote PEP 581 that proposes using GitHub for its issue tracking. Barry Warsaw has taken the initial steps and split the PEP into PEP 581 and 588. While PEP 581 gives the rationale and background, PEP 588 gives a detailed plan of how the migration will take place.
The council has requested the PSF to hire a PM to take the responsibilities of the migration. Brett Cannon adds, “…with even the PSF about potentially trying to have a PM sort of role to help handle the migration because we realize that if we go forward with this the migration of those issues are going to be critical and we don’t want any problems.”
The features or improvements Python Packaging Workgroup should now focus on
The Python Packaging Workgroup supports the efforts taken for improving and maintaining the packaging ecosystem in Python by fundraising and distributing this fund among different efforts. The efforts this workgroup supports include PyPI, pip, packaging.python.org, setuptools, and cross-project efforts.
Currently, the workgroup is supporting the Warehouse project, which is a new implementation of PyPI aiming to solve the issues PyPI users face. Last year, the workgroup came out with the Warehouse code base and in March this year they have laid out work for the next set of improvements which will be around security and accessibility. When Coghlan was asked about what are the next steps now, he shared that they are looking into improving the overall publisher experience. He adds, that though there have been improvements in the consumer experience, very fewer efforts have been put on improving the publisher side.
Publisher-side releases are becoming complicated, people want to upload source distributions with multiple wheels for different platforms and different Python versions. Currently, the packaging process is not that flexible. “at the moment the packing index is kind of this instant publish thing like you push it up and it’s done…we’d really like to be able to offer a staging area where people can put up all the artifacts for release, make sure everything’s in order, and then once they’re happy with the release, push button and have it go publish.”
These were some of the highlights from the discussion about the changes in the Python governance structure. You can watch the full discussion on YouTube:
Read Next
Mozilla introduces Pyodide, a Python data science stack compiled to WebAssembly
RStudio 1.2 releases with improved testing and support for Python chunks, R scripts, and much more!
