A panel with the new Python steering council

Over the past year, Python has moved on from the benevolent dictator for life (BDFL) governance model since Guido van Rossum stepped down from that role. In February, a new steering council was elected based on the governance model that was adopted in December. At PyCon 2019 in Cleveland, Ohio, the five members of the steering council took the stage for a keynote panel that was moderated by Python Software Foundation (PSF) executive director Ewa Jodlowska.

As is traditional for panels of this sort, the participants introduced themselves at the start—going left to right across the stage. Barry Warsaw works for LinkedIn on its "Python Foundation" team, supporting Python development at the company. He was sporting a t-shirt from "Guido van Rossum's world tour" in 1994; he went to that gathering in Maryland and "fell in love with Python" ("and Guido, of course"). He contrasted the 20 participants at that meeting with the thousands in the audience at PyCon; "pretty amazing". It is "kind of miraculous" how much the language and community has grown in the 25 years since that meeting—Python has changed many lives, including his.

Brett Cannon is a development manager for the Python extension to Visual Studio Code at Microsoft. He got started by fixing a problem that he saw in the Python Cookbook in 2002; when asked, the editor told him to post his fix to the python-dev mailing list. He kept at it and at some point Van Rossum had someone give him commit rights; "I think I was just bothering everyone a little too much". He is partly known for the phrase "I came for the language and stayed for the community"; the people on stage are a big part of that, he said.

Carol Willing said that back in 2016 she gave a keynote in the Philippines where she called Python "the people's programming language". When she started using Python in 2012, she found it to be a fun language to program in. After that, she got involved with the Jupyter project and recognized that it provided a path to learn Python, but also to learn about various scientific disciplines as well. She wanted to get more involved, so she started out "working on the community side" with the PSF and OpenHatch, then learned about the workflow and processes for doing core Python development before becoming a core developer.

Van Rossum said that when he created Python, there wasn't a language that he liked, "so I made one out of pieces I had learned previously". Since he can't write code and not have other people use it, he made Python open source, he said to loud applause. Last year, he had a case of burnout and decided it was time for someone else or some other structure to shepherd Python after doing that for nearly 30 years. He likened that to sending a child off to college; you may no longer be directly involved in their lives, but "you never stop worrying", which is why he nominated himself for the steering council. "And here I am."

Nick Coghlan came to Python as a "hardware and C/C++ guy" because he needed to test some signal-processing code. Python had the unittest module and it had SWIG, which allowed him to wrap the C++ code under test. Now he does that kind of work for fast electric-vehicle chargers for Tritium. Python is a language that allows him to "reach out and touch the real world without having to worry about all the messy details".

Questions

Jodlowska asked Van Rossum for his thoughts on Python governance and its evolution from the perspective of the former BDFL and now steering council member. Van Rossum noted that it was "pretty stressful" to be the final arbiter of anything controversial in the language; he is glad that responsibility is now distributed among the council members. He thinks that the council will have the trust of the community because it was voted in, rather than someone becoming the leader "by happenstance"

Going forward, he said that the council is structuring things differently. Instead of being the deciders of all Python Enhancement Proposals (PEPs), the council will defer most of those decisions to a chosen expert among the core developers (or sometimes outside of that group). There has only been a few months under that process, but "so far, i think that is going great". Jodlowska suggested reconvening the council at PyCon in, say, three years to see how things have gone.

The importance of having representation on the council for the scientific Python community was a question directed at Willing. She said that the council should be open to hearing from all of the different parts of the Python community. The needs of different constituencies—web, embedded, education, science, data science, and others—are going to be different at times. Having a diversity of opinions and experiences on the council will help ensure that those needs do not get lost.

Next up was the status of PEP 581 ("Using GitHub Issues for CPython"), which was still undecided at the time of the panel, but has since been accepted by Warsaw as the "BDFL delegate" for the PEP. The question was directed at Cannon, who has been a major player in the transition of various Python projects to GitHub. He noted that the implementation parts of the PEP had been split out into PEP 588 ("GitHub Issues Migration Plan"). There was a presentation on the PEPs at the Python Language Summit that was held earlier in the week and there has been some discussion with the PSF about possibly funding a "PM" (project or product manager) kind of role to help with that transition and others.

Coghlan is a member of the Python packaging working group in addition to his council role; Jodlowska asked him what the next steps for that group might be after the new Python Package Index (PyPI) was rolled out last year and once the upcoming security and accessibility work for PyPI is finished. Coghlan would like to see improvements on the "publisher side"; there have been lots of improvements on the consumer side recently, but releases to PyPI are getting more complicated

How the PEP process has changed was Jodlowska's next question, which she directed at Warsaw, who was one of the authors of PEP 1 ("PEP Purpose and Guidelines"), which describes how PEPs are meant to work. He said that the idea came out of the time when he and Van Rossum were working at the Corporation for National Research Initiatives (CNRI), which ran the Internet Engineering Task Force (IETF). He wanted a format somewhat similar to the RFC process that the IETF uses, but more lightweight. It would "just be enough process for us to get our work done without being too much process". He doesn't know how successful that last part has been, he said with a laugh.

The idea behind PEPs was that Van Rossum would not have to wade through thousands of emails to try to figure out what the proposal was; he could simply read one document that would lay out both the pros and the cons of the proposal and then make a decision. The PEP would record the decision-making process. After a while, there were parts of the ecosystem where Van Rossum didn't have the expertise to pronounce on PEPs, which is where the BDFL delegate idea came from. When Van Rossum was the BDFL, delegating was kind of the last resort for things he didn't want to decide upon; under the new governance model, though, delegates are really the first resort, Warsaw said. The council wants to "allow other people to become engaged with shaping where Python is going to go in the next 25 years".

Python 2

Jodlowska asked attendees to indicate how many were still using Python 2; both Warsaw and Cannon said that the number of hands was lower than they expected. What is the game plan after Python 2 is retired on January 1, 2020, Jodlowska asked. Cannon suggested a party, to laughter and applause.

The plans for Python 2 are moving forward and are not going to change ("thank goodness"), Cannon said. The PM role that is under discussion would also help "figure out all the little minute details" that the Python 2 sunset entails. For example, search engines often default to sending people to the Python 2 documentation, which is not the right version to go to starting in 2020. Places in the documentation where it talks about "Python 2 and 3" will need adjustment because starting in 2020 "there's just 'Python'". And so on.

Coghlan pointed attendees at a talk from PyCon AU 2017 called "Python 3 for People Who Haven't Been Paying Attention". The talk looks at some of the options going forward; the core team does expect that some commercial vendors will be offering support for Python 2 beyond 2020. The deadline is effectively saying "we're not doing this [supporting Python 2] for free anymore".

Willing said that if she looks back a few years, the transition to Python 3 was in a "very different space" than it is now. All of the top packages for Python now have versions for Python 3, for example. The scientific Python community has been using Python 3 for a long time, she said, though there is still plenty of legacy Python 2 code out there. She pointed to a keynote [YouTube video] from Instagram at PyCon 2017, on how it made the switch, for a good example of how a large company can make the business case to do the transition. A PM would hopefully help distill these "best practices" and disseminate them to help others follow that path.

The last question for the group, before taking questions from the audience, was about plans for growing and sustaining diversity within core development. Willing said that recognition that progress has been made should be first up. It wasn't that long ago, in 2017, that the first woman became a core developer. But there is "still a long way to go", she said. The council is trying to ensure that the processes and tools for contributing to Python make it easier for everyone to join in. In addition, many get their start in contributing by working on PyPI packages, so the council is trying to strengthen that ecosystem.

Warsaw added that he believed anyone in the audience could become a Python core developer; you don't have to be a C programmer, you just have to care about Python and want to learn how to become a core developer. There are many on stage and in the community who are mentoring people with the goal of bringing in more core developers. "Think about diversity in all the axes", he said. "We need everybody; there's so much work to do and so many interesting things to do that I think everybody can really contribute to Python."

Audience questions

An audience member asked what the first steps are toward becoming a core developer. Cannon suggested starting with the Python Developer's Guide, which should give people a reasonable "lay of the land" that will help them decide if it is something they want to pursue.

The biggest gaps in the language was the next question. Warsaw said that he did not see any major gaps in the language itself, but that the CPython interpreter is 28 years old. The state of the art in virtual machines has come a long way in that time, so it may be time to look at making CPython faster and able to go into even more environments than it is in now.

Coghlan agreed with Warsaw, but said that he was jealous of JavaScript's source maps as way of getting better tracebacks from modules that have been compiled or transformed in some way. Source maps allow JavaScript to essentially undo any transformations so that debuggers and other tools can see the original source code.

Another attendee wondered about core-developer burnout; does the council have any plans on how to reduce it? And is there anything the community can do to help? Cannon said that the intent is to make the job of being a core developer easier, which should help. The community can help by "being nice to core devs", he said, pointing to his keynote from the previous year. "Be nice online and that would help immensely", he said to applause.

Going back to her "people's programming language" comment, Willing noted that the core developers are all people. They have feelings, they make mistakes, they do good things, and sometimes they get things wrong; when the latter happens, "tell us—kindly". She is proud of how the core developers and greater community came together, rather than pulling apart, in the face of Van Rossum's resignation and the process of coming up with a governance model and then electing the council. She suggested that people remember that when they write and say things, there is a person on the other side of that communication.

Over a fairly short span, Python has made a transition that few other large projects have ever made. It certainly seems to have landed the project in a place that is better for Van Rossum and, in truth, for the entire Python community. With luck, there will be another steering committee panel in 2022 or so and we can look how things have gone in the interim.

A YouTube video of the talk is available.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Cleveland for PyCon.]

Index entries for this article
Conference	PyCon/2019
Python	Governance

---

to post comments