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~
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
