Python post-Guido

[LWN subscriber-only content]

Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!

Free trial subscription

Try LWN for free for 1 month: no payment or credit card required. Activate your trial subscription now and see why thousands of readers subscribe to LWN.net.

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 Heimes suggested either a triumvirate or quintumvirate (a governing body with three or five members) as a ruling body. Victor Stinner thought that the PHP process, where core developers vote on feature proposals, should be considered. Stinner's solution was not particularly popular, though. Brett Cannon put 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 Hettinger said, 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. Heimes suggested 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 Hellmann put it:

If the primary approach to decision making is to delegate unless an arbiter is absolutely necessary, then long-term consistency and stability comes less from finding individuals to commit to serving for very long terms on the N-virate as it does from everyone having a good understanding of the history of discussions and from a willingness to keep the status quo in situations where consensus isn't reached (note "consensus" rather than "unanimous agreement").

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 Warsaw suggested not publicizing the individual votes of the members, just the outcome, but Larry Hastings and others saw it differently:

I prefer more transparency in governance generally, and as a member of the community governed by this body I'd prefer more rather than less insight into the process and the thinking that went into the decision. I don't think it's a requirement for the PCOE to present as a unified front or to work in secret for them to be supportive of each other and of the body's decision.

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 Langa wondered 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 Willing likely summed up the views of many on Van Rossum's participation: "mostly I want Guido to do whatever rocks his world". Cannon had a concrete 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 help clarify 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 is organizing 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:

For the bigger decisions (and there aren't many coming up), I have some suggestions on ways to improve the discussions so that the interested parties can have a more equal say in the outcome and so that the discussions can be more time efficient (it takes too much time to keep-up with long-running, active threads).

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 Schemenauer put it in economic terms:

Perhaps this can be seen as a kind of economic problem. What is the cost of posting to a PEP discussion thread vs the cost of everyone reading that post? Or, what is the value of the comment vs what is cost for everyone to read it?

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.


Did you like this article? Please accept our trial subscription offer to be able to see more content like it and to participate in the discussion.


(Log in to post comments)

Python post-Guido

Posted Jul 17, 2018 19:51 UTC (Tue) by Tara_Li (subscriber, #26706) [Link]

Not a part of the Python community - I've ever only read snippets of code, because I hate a language where exact white space plays such a critical role. But from the outside - they're making a big mistake by moving towards a committee game.

BDFL worked *wonderfully* for the community for a long time, as far as I can see. It's working pretty darned well for the Kernel community as well. I seem to remember Perl used (or maybe still uses) something similar - the Patch Pumpkin.

The point, though, is to keep responsibility concentrated. With a committee, it gets harder and harder to pin down exactly *who* made the mistake - responsibility gets diffused, and eventually nobody owns up to stripping the threads on the screws.

An election for BDFL or Patch Pumking, or whatever makes some sense - though I would suggest requiring a fairly high majority (75-90%) to actually pick one. If it's simply 50%+1, then you have a likely significant disgruntled minority that may cause problems in the future.

Python post-Guido

Posted Jul 17, 2018 20:08 UTC (Tue) by ju3Ceemi (subscriber, #102464) [Link]

Indeed

Dictatorship is still the best "ruling" system for a "project", because it allows the few to do what is necessary for the most

It also enforce this guy's commitment, because he is taking a frontal responsability in decisions

Python post-Guido

Posted Jul 17, 2018 21:12 UTC (Tue) by edomaur (subscriber, #14520) [Link]

Well, no.

For example, the Rust language project hasn't had a BDFL since when Graydon Hoare left. And now, it has various teams handling each a set of responsibilities : Core Team is the governance and direction of the project, Language Team is the language features design team, etc. ( https://www.rust-lang.org/en-US/team.html )

It works, the language is not even as "designed by committee" as C++

And yes, there is also a CoC : https://www.rust-lang.org/en-US/conduct.html

Python post-Guido

Posted Jul 18, 2018 14:40 UTC (Wed) by malefic (subscriber, #37306) [Link]

Rust also has a bunch of people working on it full-time, backed by a large corporation with a clear set of goals. It is not a community project in a sense Python is. It is also worth mentioning that, despite all the buzz, Rust is still a niche language compared to Python, and there are probably far fewer people suggesting various "syntax improvements" on the mailing lists.

I think that dictatorship is the only way to keep Python going off the rails. Whether it's a single BDFL or three doesn't really matter.

Python post-Guido

Posted Jul 19, 2018 5:09 UTC (Thu) by edomaur (subscriber, #14520) [Link]

" It is not a community project in a sense Python is."

And how does it even matter ? The decision process is completely open and Rust is not Java even if there are corporation backed contributors. And about the "niche language" aspect, that's true that the Rust community is (at least for the moment) smaller than the Python one, but Rust is quite young too. What I tried to communicate was that it just seems to work and that from the beginning they tried to follow a scalable approach to language design.

Their is not much example of bad "dictatorized" project still around, because they tend to die or to be forked. However, I realize that perhaps I misunderstood what you were meaning with "dictatorship" : are you, by this word, speaking about arbitration authority ? Like, the Debian Technical Committee, the LibreOffice Engineering Steering Committee, how the various project in Apache are managed and so on ? Having a unique Man having the role of a local god is not the most successful way of doing community but yes, there are some real high profile exceptions. And even then, in the case of Linux it's not a dictatorship anyway, it's more a "release managership" (imho)

Python post-Guido

Posted Jul 18, 2018 14:44 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

BDFL worked *wonderfully* for the community for a long time, as far as I can see. It's working pretty darned well for the Kernel community as well. I seem to remember Perl used (or maybe still uses) something similar - the Patch Pumpkin.

Projects that start life with BDFL-style leadership can do really well with it because their leader has a chance to establish their reputation for competence while the project is small and the cost of failure is low. They also have the opportunity to learn management incrementally as the project grows around them. Finding a replacement BDFL is going to be really hard because they'll have all the management responsibilities the old BDFL without the experience and goodwill the founder had by the time they left.

I think that's why projects tend to move away from the BDFL model when the founder leaves. Having a committee instead of a single leader provides some redundancy and protection against making a bad choice in their replacement. Even projects that have a single leader rather than a committee tend to give their new leader a limited term, which at least limits the potential damage from making an unfortunate choice.

Python post-Guido

Posted Jul 19, 2018 13:28 UTC (Thu) by NRArnot (subscriber, #3033) [Link]

My first thought was whether the Python 3 language should be declared finished? (Additions to the "batteries included" libraries still allowed, provided they do not ever break the older components).

Work could then start on Python 4, under a new management.

I don't know enough to recommend this, but an idea would be to call it "Mamba" instead of "Python 4" , and in the first instance to make its primary purpose the replacement of the Global Interpreter Lock with something that's more amenable to parallelization. Would this be more possible if some small parts of the Python 3 language were removed or redefined, in ways which still allowed the majority of Python 3 code to be re-used?

My second thought was of the Norwegian Blue parrot. I still don't know precisely why.

The name "Python"

Posted Jul 17, 2018 20:11 UTC (Tue) by epa (subscriber, #39769) [Link]

It's an interesting point that a triumvirate is vulnerable to capture by an organization that employs two of the three developers. It sounds a bit paranoid to me (I don't believe commercial software companies are that evil, not even Oracle) but I can see why you have to design for the worst case.

The obvious answer is that if Python did get captured by some company, you could just fork it. Programmers and Linux distributions would soon switch to the fork if it were better managed. But then, could it still be called "Python"? Would you be risking a trademark suit by doing so?

Perhaps at the same time as Guido stepping down as BDFL, the Python Software Foundation should also step down from its control of the "Python" trademark. Their trademark usage policy talks about "the Python programming language" but this is vague and perhaps even circular. In my opinion it would be healthier to explicitly allow a broad range of uses even when the language specification has diverged (so projects like Tauthon wouldn't need to hide under different names).

Then you could be sure that even if the current Python organization gets into governance problems, Python the language and community will be able to continue.

The name "Python"

Posted Jul 18, 2018 14:46 UTC (Wed) by malefic (subscriber, #37306) [Link]

> It's an interesting point that a triumvirate is vulnerable to capture by an organization

GvR has been consistently employed by various organizations throughout his tenure as BDFL, including Google.

Ultimately, the person or persons chosen as his replacement would be people with a great deal of respect and trust. I wouldn't worry about the "capture" scenario at all.

The name "Python"

Posted Jul 18, 2018 17:38 UTC (Wed) by antiphase (subscriber, #111993) [Link]

> I wouldn't worry about the "capture" scenario at all.

Nice try, Microsoft.

Python post-Guido

Posted Jul 18, 2018 2:40 UTC (Wed) by gus3 (subscriber, #61103) [Link]

I see this as Guido doing an experiment on a stable project: crowd-sourcing a new management scheme. Of course, I could be wildly wrong; I don't have any particular insight into Guido's mind. I don't even use Python on any regular basis, but my ex-wife certainly does. (No, that isn't why she's my ex. I promise.)

I just bought a "starving hacker" subscription to LWN.net, in order to read this article & see how the immediate aftermath is playing out. I'll admit, I like what I see.

Oh, and you're welcome. It's the least I could do, to repay Mr. Corbet. After all, he helped me write a working kernel device driver.

Python post-Guido

Posted Jul 18, 2018 3:52 UTC (Wed) by marcH (subscriber, #57642) [Link]

> What is the cost of posting to a [PEP] discussion thread vs the cost of everyone reading that post?

Basically the definition of the Internet. Let us know when the Python community has a fix.

But why?

Posted Jul 18, 2018 9:37 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

It remains unclear to me why language developers are so sure that they _need_ a mechanism by which controversial changes to a successful languages get made. I very much doubt that it matters which hopelessly inappropriate mechanism you choose, the problem of "Let's make this change lots of people oppose" isn't fixed by having a triumvirate, or choosing by coin tosses, or apantomany ("if the next bird I see is a swan, we're applying the patch").

But why?

Posted Jul 18, 2018 9:38 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

Ugh, s/apantomany/apantomancy/ - Diviniation through chance encounters.

But why?

Posted Jul 18, 2018 15:02 UTC (Wed) by malefic (subscriber, #37306) [Link]

> the problem of "Let's make this change lots of people oppose" isn't fixed by having a triumvirate

PEP 572 is an outlier. Most PEPs are accepted or rejected without so much fuss, even when there's some opposition. PEP 498 (Literal String Interpolation) in Python 3.6 was also vigorously opposed ("why do we ever need a *fourth* formatting method??!"), but is now accepted as one of the best features of Python 3. The BDFL is there to make the final decision, however unpopular at the time of inclusion, and to provide overall design consistency through their vision and taste. This is much better than making decisions through a coin toss.

But why?

Posted Jul 19, 2018 14:42 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

[Meant to post this some time ago but forgot LWN has a "confirm" step instead of editing comments]

But do you think ramming through PEP 498 worked out better because this is generally a good way to do things and PEP 572 was just bad luck?

I'm looking back at things like PEP 414 (unicode literals in Python 3 so that more Python 2 code "just works") and I see plenty of effort put into figuring out what's actually objectionable here, let's narrow this down and do just the minimum possible to make the most people happy while annoying as few as possible.

My feeling is that with PEP 498 there was an attempt to shortcut, "I can't be bothered to persuade these people that I'm right, so we'll just do it, and then hopefully they'll come along".

But that's doubly risky, the least awful outcome is that you were right but you alienate loads of people and cause unnecessary strife, which seems to be what Guido thinks happened here. And actually it's also possible that since you insisted on doing it anyway you were wrong, you will eventually _realise_ you were wrong and so either it's going to get reversed out or the language will fade away ("Remember when Python didn't have that stupid assignment bug?").

Again, I bring this up because we're talking about programming languages here. This is not a penalty shoot-out, we have great luxury of time. What would be the negative consequences of PEP 572 taking twelve months, or five years to search for consensus ? Other than those in favour didn't want to wait?

Late breaking development

Posted Jul 18, 2018 16:31 UTC (Wed) by jake (editor, #205) [Link]

Barry Warsaw has presented an alternative idea for Python governance in a lengthy post to the committers list:

https://www.mail-archive.com/python-committers@python.org...

He proposes continuing with the idea of a BDFL backed by a council that would provide some assistance to the BDFL as well as some checks and balances on their power should things go awry. He suggests that Brett Cannon fill that role:

> I think he’s the perfect candidate, and he’s already demonstrated qualities that I think
> make him a fantastic leader. He’s smart, compassionate, passionate,
> respectful, young, tall, and has the right mix of technical excellence and
> social skills. He believes deeply in diversity and community. As he’s shown
> with the decisions to move first to Mercurial, then to git/GitLab, he isn't
> afraid to make difficult decisions that he knows not everyone will agree with
> (and I say that having advocated the losing choice more than once :). He’s not
> afraid to say what’s on his mind. I think he can clearly articulate a Vision.
> He shares many of these same qualities with Guido, while being a different
> person with different sensibilities. And that is not only fine, but IMHO a
> *good* thing. We can trust his stewardship, and he already has legitimacy as a
> senior decision maker in the Python ecosystem. He has a wide technical
> knowledge of Python and its C implementation, and yet he knows what he doesn’t
> know. He has good relationships with most core devs, and is a well-known voice
> within the wider community. He’ll be able to delegate where appropriate, and
> make definitive pronouncements where needed.

So far, the reaction has been quite positive. We will be keeping an eye on things and write more about this transition in the future. Stay tuned ...

jake

Python post-Guido

Posted Jul 19, 2018 23:19 UTC (Thu) by gerdesj (subscriber, #5446) [Link]

"n-virate" is going to need someone to come up with a non sexist version of that term. The original or at least most famous triumvirate - JC and Co - was at least accurately descriptive: there were three men. Vir means man in Latin, so perhaps something involving populi might work instead.

::...


免责声明:
当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
内容版权归原作者所有;
本人对内容的有效性/合法性不承担任何强制性责任.
若有不妥, 欢迎评注提醒:

或是邮件反馈可也:
askdama[AT]googlegroups.com


订阅 substack 体验古早写作:


点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

关注公众号, 持续获得相关各种嗯哼:
zoomquiet


自怼圈/年度番新

DU22.4
关于 ~ DebugUself with DAMA ;-)
粤ICP备18025058号-1
公安备案号: 44049002000656 ...::