PEP 8010 - The singular leader

[brettcannon]

@hynek

I find it an overstatement that Guido always had grand vision for Python

But is that a good thing? As Barry pointed out, Guido implicitly had a vision in his head whether he meant to have one or not. I mean you could say the vision was nothing more than “what Guido says is Pythonic”, but there was still something guiding him.

And based on how others have expressed worry about how things will move forward maybe we should start talking about a general vision to help communicate what is in people’s heads. So even if Guido didn’t have a specific vision I don’t think that should preclude having one going forward.

[pitrou (Antoine Pitrou)]

@brettcannon

As Barry pointed out, Guido implicitly had a vision in his head whether he meant to have one or not.

So does everyone (we all have intuitive thoughts and preferences, regardless of whether we are aware of them and articulate them publicly). So I’m not sure whether this is really saying anything interesting about Guido, or about the BDFL model.

@brettcannon

And based on how others have expressed worry about how things will move forward maybe we should start talking about a general vision to help communicate what is in people’s heads

I’m curious what that could look like
The one thing I know about is the Zen of Python, but it’s deliberately vague, and often violated, even by the staunchest pythonists.

[hynek (Hynek Schlawack)]

@brettcannon

So even if Guido didn’t have a specific vision I don’t think that should preclude having one going forward.

My point isn’t that having a specific vision is bad; my point is that I don’t think that it’s possible for a mere mortal to have one that works. It’s basically waterfall++.

In the end we’d be choosing one gut feeling over another because we had someone with a good gut feeling before.

[barry (Barry Warsaw)]

I don’t see it that way, I see it as helping to set and evangelize a directional vision for the language, and I don’t see why some one person can’t fill that role. They will never have to do it alone, and their vision will never be implemented if it runs counter to what the community wants. But it can be very useful to have that directional vision for the language so it doesn’t just accrete new features based on the whims of whomever is active in the development community at the moment.

An example I bring up often: if you could speed up CPython by 2x by breaking some of the C API, should we do it? There’s no clear answer one way or the other. So do we just let inertia and the status quo win by default? Or do be be bold but careful and do it?

[pitrou (Antoine Pitrou)]

@barry

An example I bring up often: if you could speed up CPython by 2x by breaking some of the C API, should we do it? There’s no clear answer one way or the other. So do we just let inertia and the status quo win by default? Or do be be bold but careful and do it?

Why do we need a single person’s directional vision for that, rather than a community debate and a vote? Other programming language communities seem to have no problem evolving, even without a BDFL.

[barry (Barry Warsaw)]

Are they as big and diverse as Python? I worry that there will be so many competing visions, it will be more chaotic than consistent. I’m not saying that will happen, but I think it’s a possibility that must be considered.

[vstinner (Victor Stinner)]

I dislike the expression “vision”. I prefer to talk about interest areas and expertise. I am not interested in the typing module nor IDLE. Let’s say that I work 5 days per week on Python. My time is limited. If I become the new BDFL, I have 6 PEPs but it takes me one day per PEP. What should I do with the IDLE or typing PEP? Defer it? IMHO Python became too popular to have a bottleneck of the head of its hierarchy. That’s why I tried to distribute the responsibilities between “Python teams” in my PEP 8015.

With a single BDFL there is a bottleneck in the availability of the BDFL, but also a very high pressure on taking decisions. If the pression is too high, the risk is also to not take a decision to have to deal with the haters on the internet. (Did you read the reactions on the Internet on the acceptance of the PEP 572?)

@barry

Are they as big and diverse as Python? I worry that there will be so many competing visions, it will be more chaotic than consistent. I’m not saying that will happen, but I think it’s a possibility that must be considered.

That’s an obvious problem, right. IMHO we no longer have the luxury to attempt a new BDFL. But that’s just my opinion

I also disagree that core devs don’t want or are unable to design a consistent Python. While sometimes people disagree on what is “Pythonic” or not, IMHO we all agree on most parts of what is Pythonic.

[pitrou (Antoine Pitrou)]

@barry

Are they as big and diverse as Python?

I don’t know how to measure diversity, but for a quick quantitative comparison with Rust:

• CPython has 8 contributors with more than 200 commits since 2016
• Rust has 24 contributors with more than 200 commits since 2016

If we look for lines of code added, the comparison result is roughly similar : 27 contributors added more than 10000 lines of code to Rust since 2016, 14 did the same for CPython.

So at least it seems Rust is as “big” in terms of contributors / contributions as CPython is. But perhaps you meant something else, such as number of use cases, or the breadth of the overall community. If the latter, it’s clear Python is much bigger. But for me that would be an argument against a BDFL, since it’s unlikely the BDFL would have a clear and detailed view of all kinds of uses of Python (while it’s easier for something more specialized such as R or PHP).

[gpshead (Gregory P. Smith)]

A detail to consider: one of the decisions may well be changing the CPython release cadence. So specifying things in terms of 3 releases expected to be 4.5 years would need disambiguation if releases were made more or less often.

[barry (Barry Warsaw)]

That’s a good point. I’m trying to balance consistency over several releases vs. length of term. Should we say “three releases”?

[barry (Barry Warsaw)]

@vstinner

I dislike the expression “vision”. I prefer to talk about interest areas and expertise. I am not interested in the typing module nor IDLE. Let’s say that I work 5 days per week on Python. My time is limited. If I become the new BDFL, I have 6 PEPs but it takes me one day per PEP. What should I do with the IDLE or typing PEP?

“Nothing” or “delegate” is a fine answer. It worked for Guido after all.

Those aren’t problems I’m concerned with. Delegation and team work is going to be part of every governance proposal; Python is simply too big to do otherwise. But OTOH, there are plenty of peripheral bits of Python that don’t affect the overall vision, unless you want them too. For example, what if someone decided to make type annotations mandatory? There might be good reasons for or against, and like previous examples, there may not be a clear consensus, and maybe a vote wins by 1. Does that mean it’s a good thing to add to the language? Some authority has to weigh the pros and cons and make a decision in the best interest of Python, even if it isn’t the most popular decision (e.g. a vote win by 1 would mean it goes in, but maybe it’s not Pythonic).

We trusted Guido’s vision for the language even if it wasn’t always explicit. I think we can find new BDFLs whose vision we trust, and there will always be checks and balances against despots and alligators (anti-Pythons?).

[encukou (Petr Viktorin)]

@barry

That’s a good point. I’m trying to balance consistency over several releases vs. length of term. Should we say “three releases”?

What if „three releases“ ends up meaning 18 months? Or 9?
What about leaving this for later? e.g. add a paragraph like this:

If Python’s release cadence changes, the length of GUIDO’s term should change to 4.5 years rounded to whole releases. How the rounding done is left to the potential release cadence PEP.

[barry (Barry Warsaw)]

https://github.com/python/peps/pull/815

[dstufft (Donald Stufft)]

In reviewing the PEP, I noticed a few potential issues:

PEP 8010 calls out to PEP 8001 for the voting mechanisms used in several places, however PEP 8001 does not use a secret ballot. While it might be arguably OK for basically choosing our “government”, when voting on actual individual people having public ballots seems like it would stifle people’s willingness to vote honestly. If I’m running for GUIDO, and Barry is my friend, but doesn’t think I’d be a good GUIDO, is he going to feel comfortable ranking me lowly? This can get even worse in cases where a vote of confidence happens, because it’s effectively an “aggressive” action, and having public ballots is likely to make people extremely unwilling to actually vote to depose a GUIDO.

The entire CoP seems like a solution looking for a problem. I see that they appear to have 3 responsibilities:

• Advise the GUIDO.
• Initiate the proceeding to recall a GUIDO.
• Rule on PEPs written by the GUIDO.
  • It’s unclear if this is true, the PEP seems to say that both the CoP and the GUIDO have ultimate authority on PEPs, but I think it’s trying to say the CoP has ultimate authority on the GUIDO’s PEPs.

The advisory role appears to be kind of… silly? to me. Presumably whoever the GUIDO is, is likely to already have people they trust and know within the community who they’re going to go to to talk to and hash out design issues. Those people may be part of the CoP or may not, but it seems unlikely that the CoP is going to be providing something useful in terms of an advisory position for the CoP. Ideally the GUIDO should be getting advice from a wide range of people, and who it makes sense to get advice from may vary wildly from PEP to PEP. This almost feels like a parent trying to arrange friends for their children…

Recalling a GUIDO is probably the biggest, unique, responsibility of the CoP. However it seems to me like having an elected group of people whose role is to trigger a recall vote seems like a level of misdirection we are unlikely to require. I think we should easily get along just by saying that any core developer can motion for a vote of confidence in the current GUIDO at any time, and if another core developer seconds their motion that we trigger a vote and let the entire body vote then. Adding the CoP seems to be like a premature optimization since I don’t think we’re likely to run into core developers deciding to motion for a vote of no confidence just for funsies (especially if it requires a second to actually trigger it).

Additionally, the recall vote also uses the voting mechanism in PEP 8001, which doesn’t really make much sense I think because there are only two options (Yes or No), and when there are only two options all vote systems are basically the same (pick the one you want), but it might be useful to impose additional rules on a recall vote. One example that I can think of off the top of my head, is that it might be a good idea to require a recall vote to pass with a super majority since it is intended to only be used in the case of a GUIDO going off the reservation and causing grievous harm to Python-- and in those cases it seems like a super majority of Python core should be willing to depose the current GUIDO.

Finally, the CoP’s last responsibility that I can find is to act as the arbiter when the GUIDO writes a PEP themselves. Personally, we’re already entrusting the GUIDO with a lot of power, additionally giving them the power to select a Delegate doesn’t seem like a large leap. If we’re worried about the GUIDO picking someone who they know will approve their PEP, regardless of what consensus is (which seems like a case for a recall TBH), maybe make it possible for any core developer to veto the Delegate the GUIDO picks within some set time frame of the announcement of the Delegate.

Al of that seems like it would greatly simplify this PEP by moving some powers out of the CoP, and into the broader core developer body, under the idea that the broader core developer body are not likely going to randomly trigger “aggressive” actions like votes of no confidence or veto’ing a GUIDO’s own PEP-Delegate just for funsies.

[dstufft (Donald Stufft)]

FTR I would probably say this is better framed as electing a Technical Lead for the Python project, rather than electing a BDFL, since we’re not electing a Dictator (since we can recall them) and it’s FL (length of service is 3 releases, upon which they can run again).

[dstufft (Donald Stufft)]

One final thing:

The PEP isn’t clear on who can decide changes to PEP 8001, but it uses PEP 8001 for the decision making process. It does say that PEP 8001 is used for deciding changes to PEP 8010, so it should probably additionally clarify that PEP 8001 is also used for changes to PEP 8001, and that the GUIDO (and the CoP if it exists) are not the final arbiter for those PEPs, as together they effectively form the “constitution” for Python, and thus changes to them should be left to the broader group.

[willingc (Carol Willing)]

I like the reframe to technical lead as that encapsulates the responsibilities well.

[barry (Barry Warsaw)]

@dstufft

however PEP 8001 does not use a secret ballot.

I would argue for secret ballots for PEP 8010. I’m happy to amend the PEP to be clear about that.

@dstufft

It’s unclear if this is true, the PEP seems to say that both the CoP and the GUIDO have ultimate authority on PEPs, but I think it’s trying to say the CoP has ultimate authority on the GUIDO’s PEPs.

Yes, that’s my intent. If you have suggestions for better language, let me know, otherwise I’ll take a crack at clarifying it.

@dstufft

Those people may be part of the CoP or may not, but it seems unlikely that the CoP is going to be providing something useful in terms of an advisory position for the CoP.

Perhaps. I certainly don’t intend to force the GUIDO to consult the CoP, but I think there are cases where a higher bandwidth, more detailed technical discussion would be needed before pronouncement. These would be people the GUIDO could trust to have a global view of Python, rather than a narrow focus on one particular topic. They may also be in a good position to do some research before pronouncement (e.g. “let’s try to find out how many projects would be affected by new syntax X”).

@dstufft

Adding the CoP seems to be like a premature optimization since I don’t think we’re likely to run into core developers deciding to motion for a vote of no confidence just for funsies (especially if it requires a second to actually trigger it).

I’m not so sanguine about that, but perhaps I underestimate the core developers. The scenario I was thinking about was PEP 572. Given a nearly even split on that decision, what are the odds that someone on the losing side would have triggered a vote of no confidence? And it would have been easily seconded perhaps. Do we want the GUIDO pronouncing in fear of recall? I definitely do not.

@dstufft

and in those cases it seems like a super majority of Python core should be willing to depose the current GUIDO

That was my thinking too, but the PEP probably needs to be clarified.

@dstufft

Al of that seems like it would greatly simplify this PEP by moving some powers out of the CoP, and into the broader core developer body, under the idea that the broader core developer body are not likely going to randomly trigger “aggressive” actions like votes of no confidence or veto’ing a GUIDO’s own PEP-Delegate just for funsies.

I envisioned the CoP as a backstop against that type of behavior. If a recall can be triggered by a two core developers working in concert, then we can have an overwhelmingly honorable core developer community, but two disgruntled members can cause a lot of havoc. A CoP ought to be more reserved.

[njs (Nathaniel J. Smith)]

@barry

These would be people the GUIDO could trust to have a global view of Python

The idea of the core devs voting to decide who the GUIDO can trust does strike me as very weird.

@barry

The scenario I was thinking about was PEP 572. Given a nearly even split on that decision, what are the odds that someone on the losing side would have triggered a vote of no confidence? And it would have been easily seconded perhaps. Do we want the GUIDO pronouncing in fear of recall? I definitely do not.

In a situation so tense that a vote-of-no-confidence is “easily seconded”, then I think the alternative to a vote of no confidence would be a constitutional crisis. Guido can make unpopular pronouncements because his authority is based on a vast reservoir of personal trust and precedent. A GUIDO’s authority is instead based on community support as measured by votes; if the community support goes away, then something will have to give. If people can’t call to depose a GUIDO, then they can instead call for a PEP 8001-based election to throw out the whole concept of GUIDOs and switch to another governance model entirely. And any smart GUIDO will know this, and it can (should!) affect how they approach things.

For better or worse, I simply don’t see any way that something like PEP 572 could go through under any governance model besides Guido-as-BDFL, at least with the discussion handled the way it was. I’m fine with that; I don’t think being able to pass PEP 572 is crucial for Python’s continued success or anything. But we should acknowledge it.

I was actually very surprised when I finally read PEP 8010. I was lazy about doing this because I assumed I knew what it was from the title (“The BDFL governance model”), but then when I read it I was like wait a sec, you can’t call it a BDFL if there are regular elections and a mechanism to depose them! It’s more like a strong mayor model or something…

[vstinner (Victor Stinner)]

@dstufft

PEP 8010 calls out to PEP 8001 for the voting mechanisms used in several places, however PEP 8001 does not use a secret ballot. While it might be arguably OK for basically choosing our “government”, when voting on actual individual people having public ballots seems like it would stifle people’s willingness to vote honestly. If I’m running for GUIDO, and Barry is my friend, but doesn’t think I’d be a good GUIDO, is he going to feel comfortable ranking me lowly?

Aha, this an interesting question. In my PEP 8015, the vote for Steering Committee members is private during the vote (1 week), but then all results are public (not anonymous). I don’t trust voting systems, so I would like to be able to verify that my own vote has been accounted properly. If results are anonymous, how can I check results?

Currently (current “Guido BDFL governance”), votes to promote a core developers are public on the python-committers mailing list (archives of the list are public). It can already sensitive to vote against a contributor which can later become your colleague (core developer as you). But it seems like the system works, and most votes get a -1 vote.

My preference goes to full transparency, even if it has the flaw that you described. Maybe you can loose a friend with a vote, you have to deal with that