[python-committers] And Now for Something Completely Different

[Ethan Furman]

On 07/19/2018 04:47 PM, Victor Stinner wrote:

> or: Replace Dictatorship with Democracy.
>
> Hi,
>
> == Introduction: unjustified fears? ==
>
> I see that many people are eager to replace the old governance based
> on a single BDFL with a new governance with a new BD(FL) and/or a
> council. My problem is that I don't see any clear definition of the
> roles of these BD(FL) and/or council: what they are expected to do,
> what they cannot do, etc.

I imagine that will be made clear in that proposed PEP.

> It seems that the main question for a new governance is how to take a
> decision on PEPs (accept or reject them with some variants like
> Deferred). I read that core developers are unable to make a decision
> themselves (fail to reach a consensus) and that letting core
> developers decide would make Python "inconsistent" (as if only a
> single BDFL is able to keep Python consistent). I also read that the
> BDFL is required to make unpopular decisions to enhance Python.

This is, unfortunately, true -- with 100+ core-devs (give or take a few) that's basically 100+ different visions of 
Python, and on any particular issue the majority will be made up of different core-devs, therefore different visions 
will be approving/rejecting the PEPs, and internal consistency becomes impossible.

> Can someone please explain me the rationale behind these fears? Do you
> have examples? Maybe examples outside Python?

Examples inside Python are good enough:

- PEP 435 (Enum)  [accepted]
   lots of minor decisions from BDFL about this or that choice, and still there
   were about 1,000 emails over several threads

- PEP 461 (%-formatting for bytes and byte arrays) [accepted]
   IIRC there was lots of push-back on adding this to bytes and byte arrays

- PEP 463 (exception-catching expressions) [rejected]
   lots of discussion here, not sure if it would have been accepted by majority vote

- PEP 572 (assignment expressions) [accepted]
   'nough said

> In my experience, a consensus has been reached in less than one month
> on most PEPs without the help of the BDFL. There were a few
> controversal PEPs. The most controversial PEP is obviously the latest
> accepted PEP, the PEP 572 (assignment expressions). OK. But do you
> have other examples?

See above.

> I propose to trust core developers judgment and let them all decide if
> a PEP should be accepted (or rejected). Common PEPs would require
> "50%+1" majority (1/2), sensitive PEPs (ex: modify the Python
> language) would require 66%+1 majority (2/3).
>
> Known experts will help to lead the discussion and to refine the PEP.
> Core developers will decide when they consider that a PEP is mature
> enough for a vote.

My first issue with this model is, as discussed above, a lack of a consistent vision.  A BDFL is not just there to say, 
"this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely 
not something easily done by 100+ voters.

My second issue is qualifications:  there are plenty of PEPs that I either have no interest in or whose field I have no 
experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP.

My third issue is, quite simply, time.  Working on patches takes time; reviewing PRs takes time; and being a good voting 
citizen takes lots and lots of time -- and we're all volunteers.  Time is at a premium.

--
~Ethan~