(separate reply to discuss the "what do we do now" topic)
On 07/12/2018 07:57 AM, Guido van Rossum wrote:
I would like to remove myself entirely from the decision process. [...]
I am not going to appoint a successor.
So what are you all going to do? Create a democracy? Anarchy? A
dictatorship? A federation?
Although the timing is a surprise, the idea of Guido retiring isn't. I
remember shooting the breeze with Guido about it as far back as the
Santa Clara PyCons--and I'm sure the topic goes even further back. So
we've had quite a while to think about it. Here's my opinion, which I
reached years ago and haven't appreciably changed since.
First, there's no single person in the community who can take over as
BDFL. It's simply impossible. The Guido we have today is who he is
because he's been doing the BDFL job for more than twenty years. The job
has shaped and taught him as he did it; as Python grew, so did Guido.
Literally anybody else we might appoint as BDFL would have to start
fresh and grow into the job--and I don't think we can afford the growing
On the other hand, I also think that deciding PEPs by popular vote would
be folly. Python is mature enough to be simultaneously robust and
fragile, and leaving its design up to popular vote seems like a recipe
for chaos. In my opinion, the final arbiters of Python's evolution
should be experts, not the masses. (Cue "Twitch Plays Pokemon" here.)
I think the happy medium is a Council Of Elders. Summarizing this approach:
* The number of Elders on the Council should be an odd number greater
than two. It can't be one person, as that'd just be a BDFL. And we
want an odd number to prevent tie votes. My instinct is that three
would be fine.
* For most PEPs the Elders should delegate, just as Guido has
generally done in the last few years. Although I expect the Elders
to be seasoned Python core developers, they probably won't have
domain-specific knowledge necessary to rule on most PEPs.
* I'm not sure how to appoint the initial round of Elders. Maybe a
* However, once appointed, Elders are appointed is "for life". The
only way to remove one would be for them to voluntarily step
down--there would be no mechanism to remove one from office.
(Perhaps this is too strong--perhaps one could be removed by a
unanimous vote from all other Elders?) I want the Council to be
immune to popular opinion, to be empowered to do what they think is
right without fear of anything beyond negative public opinion.
* I'm not sure how we'd replace Elders. Maybe they'd hold an
internal-only election? ("Jo has decided to step down, and we have
elected Sam as Jo's replacement.")
Your reaction to this might be "but running Python's evolution by
committee will slow it down!" I suspect that's right. Not being Guido,
I think the Council would be more cautious in approving changes to the
language. But I think that'd be appropriate anyway. Python's already a
fine language, and I can live with it evolving more slowly in the future.
Personally I'd nominate the following three Elders. In alphabetical order:
* Barry Warsaw (knows where the bodies are buried)
* Benjamin Peterson (young enough that we'll get many years of service
out of him)
* Brett Cannon (the only candidate tall enough to be worth considering
as BDFL replacement)
I like this union of experience and personality. My intuition is that
they'd find the mixture of caution and let's-go-for-it spirit that we
need to keep Python moving forward without making too many mistakes.
And we could call them "the B's" for short!
Finally, I agree with Raymond's call for slow deliberation. Python's not
going anywhere, there are no burning needs for changing the language
that need to be addressed immediately. We can all collectively sit and
stew on this for a while.
/p.s. I know nobody is suggesting this, but I'll preemptively say it
anyway: let's not simply appoint all the Release Managers as our initial
Council Of Elders. While that'd net us some very fine Elders indeed,
you'd also wind up with me on the Council--an obvious mistake!
python-committers mailing list
Code of Conduct: https://www.python.org/psf/codeofconduct/