Python post-Guido

By Jake Edge

July 17, 2018

The recent announcement by Guido van Rossum that he was stepping away from his "benevolent dictator for life" (BDFL) role for Python was met with some surprise, but not much shock, at least in the core-developer community. Van Rossum has been telegraphing some kind of change, at some unspecified point, for several years now, though the proximate cause (the "PEP 572 mess") is unfortunate. In the meantime, though, the project needs to figure out how to govern itself moving forward—Van Rossum did not appoint a successor and has left the governance question up to the core developers.

Van Rossum has been burning out over the last few years, at least partly due to keeping up with contentious discussions for PEPs he is interested in. The discussion around PEP 572 ("Assignment Expressions") is quite probably the worst offender in the history of Python. It spanned multiple enormous threads, on two different mailing lists (python-ideas to start, then to python-dev once it was "ready"), spawned two separate polls (neither of which were favorably inclined toward the feature), and seemed, at times, interminable. Perhaps the most irritating part of it was its repetitive nature; the same ideas were brought up time and again, no matter how many times the PEP's authors (originally Chris Angelico, who was joined by Van Rossum and Tim Peters toward the end of the process) and others repeated the arguments against them. It was clear that many were just reacting emotionally (and sometimes histrionically) to the proposal: not reading the PEP or any of the discussion, then loudly proclaiming that their opinion was clearly the only sensible one.

Van Rossum said he would be sticking around " for a while " as a regular core developer, but he left it to the community to determine the governance of the project moving forward. He seems curious to see what develops: " So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation? " As many noted in the resignation thread, it was hoped that he would continue as BDFL for some time to come; leaving because of a contentious PEP discussion, rather than a simple retirement decision, is particularly sad. Amid all of the well wishes, many of the replies to Van Rossum's announcement did what the Python community so often does: rolled up its sleeves and got down to work.

New governance

There were two main areas that Van Rossum called out for governance: how PEPs are decided and how new core developers are added. The latter seems to already be based on a vote of the existing core developers. They are the only ones allowed to post to the core-committers mailing list, which is where Van Rossum posted his resignation, presumably to avoid wading through hundreds of messages—nearly all undoubtedly positive and grateful, though surely there would have been some trolls as well.

For PEPs, and any other major language decisions, Christian Heimessuggested either a triumvirate or quintumvirate (a governing body with three or five members) as a ruling body. Victor Stinnerthought that the PHP process, where core developers vote on feature proposals, should be considered. Stinner's solution was not particularly popular, though. Brett Cannonput it this way:

For me, I think a key asset that Guido has provided for us as a BDFL is consistency in design/taste. Design by committee through voting does not appeal to me at all as that can too easily lead to shifts in preferences and not have the nice cohesion we have with the language's overall design, especially considering that there will always be subjective choices to make (someone has to eventually choose the colour of the shed). People, including me, have also pointed out that by having Guido to look up to you we have had a very consistent view of how the community should behave and that too has been an asset. IOW I don't like Victor's proposal. ;)

The idea of a triumvirate (or an N-virate for some small, odd N) has seemed to gain some traction, though who would be on it, how long they would serve, and other details are still being discussed. There is also the inevitable question of what the name of such a group might be, with various ideas—some perhaps more serious than others—being suggested. But, as Raymond Hettingersaid, there is no real rush:

For the time being, I propose that we shift into low gear and defer major language changes for a while -- that will give us time to digest the changes already in motion and it will give the other implementations more of a chance to catch up (we've been out-running them for a while).

Much of what has been discussed is the PEP decision-making process and how that will change. Prior to his resignation, Van Rossum was the final arbiter of PEPs, except where he delegated his power to a BDFL-Delegate. Many see the role of the "Python Council of Elders" (PCOE) or the "design stewards" (two of the more popular names for the governing body) as largely finding the right person to delegate to for the decision on a given PEP. That group would also be the deciding body of last resort if consensus on a decision is not being reached.

But there is also the question of how long people serve on such a body. Some are calling for "lifetime" appointments with an understanding that folks can stand down at any point, while others would like to see people rotate out of those positions over time. Before that can be determined (presumably via a PEP or set of competing PEPs), though, the role of the group has to be determined. Heimessuggested three functions:

• Primary to delegate responsibilities to domain experts
• Secondary to provide consistency and trust
• Lastly to have final word in case of controversial bike shedding

If the main role is to delegate, though, there is less of a need for it to be a lifetime job. As Doug Hellmannput it:

Building the system to support and encourage turnover, like we do with release managers, lowers the level of effort someone is signing up for when they agree to serve. Given the *many* discussions of burnout in the Python community and open source in general, that seems like an important feature.

How decisions would be made and communicated also came up. There were suggestions of requiring a unanimous vote by the body, but that may be too restrictive. Barry Warsawsuggested not publicizing the individual votes of the members, just the outcome, but Larry Hastings and otherssaw it differently:

Sunlight, not darkness,

Hastings and others see the PCOE as being akin to the US Supreme Court—a body that only makes decisions when there are disputes that can't be resolved any other way. But Łukasz Langawondered why having three members was so popular:

I see a bunch of problems with such a low number, like the ability for a single corporation to take over the design process of Python by employing just two of the three members (consistently voting over the third one). 3 also has high likelihood of ties if one of the members abstains. And so on.

Constitution

He also was concerned with how the role of the design stewards will be determined: " Python needs a 'constitution' which will codify what the council is and how it functions. " Many are calling that document "PEP 2", but how it would be accepted given the situation is completely up in the air. Langa had a suggestion, but one that might not be popular with Van Rossum: " Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers? "

That sentiment was shared by many in the thread; it is clear that there is nearly universal hope that Van Rossum will still have an active role—perhaps even as a BDFL-Delegate on some PEPs. Carol Willinglikely summed up the views of many on Van Rossum's participation: " mostly I want Guido to do whatever rocks his world ". Cannon had aconcrete idea if Van Rossum is willing: " In my ideal scenario, people write up PEPs proposing a governance model and Guido chooses one, making it PEP 2. "

For his part, Van Rossum did briefly pop into the thread to helpclarify his role in deciding on governance: " I’m still here, but I would like to be out of the debate and out of the decision loop. I’m also still President of the PSF [Python Software Foundation]. But this is not for the PSF to decide. You all are doing fine. "

So "divine intervention" of a sort is probably not in the cards. The core developers are going to need to figure this out for themselves. Willing suggested that there be two guiding principles in determining a governance model: " If what evolves embraces the Zen of Python [ PEP 20 ] and 'I came for the language and stayed for the community', I am confident that the language will benefit technically. " Indeed, the Python community is a strong one, which is a testament to Van Rossum's leadership over the last 28 years or so.

As part of the process of coming up with a governance plan, Nathaniel Smith isorganizing an informational PEP to survey the governance of other open-source projects. The idea would be to see if there are parts and pieces that could be used for Python. Another effort, some of which even predates Van Rossum's resignation , is to figure out a better way to discuss PEPs and to try to reach consensus on them. Hettinger suggested one possibility:

Essentially the idea would be have a wiki/faq editable by all the participants. It would include the key examples, arguments for and against, and rebuttals which can be collected into a current-state-of-the-conversation. This would be somewhat different than the current PEP process because currently PEP authors dominate the conversation and others can get drowned out too easily. (This idea is modeled on the California Legislative Analyst Voters Guide which summarizes proposals and has statements and rebuttals from both proponents and opponents).

Neil Schemenauerput it in economic terms:

With the current discussion method, the costs are often disproportionate. You have hundreds of people reading the thread. So that cost is pretty high. Posting a half-baked comment is too easy. Starting a new thread with a new subject line is too easy.

He suggested a separate mailing list for PEP discussions once they had finished their run on the " free-wheeling wild west " of the python-ideas mailing list. The PEP-discussion list would have some ground rules to try to maximize the use of everyone's time. Disproportionate cost for fully engaged participants versus a Python user or developer who just wanted to vent likely played a big role in the burnout that led to Van Rossum's resignation.

It's clear that it will take some time for the dust to settle and for concrete plans to be formulated, but one gets the sense that the Python community is ready—even if not entirely willing—for self-governance. The process will play out in the open, though, which is likely to be helpful to other projects that go through similar, or even dissimilar, transitions. In the open-source world, projects can learn a great deal from each other, from a technical perspective, of course, but also in areas like governance and community.

We would be remiss not to add our own "thank you Guido" to the pile. Our site depends on Python and has for 16 years or more. Van Rossum has done the world a great service with his efforts—that seems unlikely to change even after all of this is behind us. In many, many ways, the Python community is a reflection of its BDFL; its generally pleasant tone and overall friendliness to everyone is something that plenty of other projects should try to emulate.

(

to post comments)