> On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstin...@redhat.com> wrote: > > 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.
I think the core difference behind all of the proposals, when you get down to brass tacks, will be the vision for where the langauge goes. There are independently good ideas that maybe should not be accepted, because they compromise the vision for the worse, or ideas that seem poor on the tin but that once they get added they mesh well with the overall language. The further you scale up the number of people directly deciding the direction of the language, the more likely you will find inconsistency. No two people have the same design sense, and so if you ask two people you're likely to get at least two answers. Of course with many things, there are grey areas. If you have some sort of council of N developers, with a small enough N you can arrive at a place where the design sense for all of N are closely enough aligned that the inconsistency produced by them are minor enough as to not be noticeable. However, the larger you make that group, the more likely you are to introduce larger and larger inconsitencies. Now, that doesn't mean that focusing on consistency to the end of all other things is the right choice. The laws of any democratic country tend to be extremely inconsistent, due to that very reason, but most people would not argue that we should revert democracy back to dictatorships in those countries. Democracy brings with it more power to the "masses" and helps protect against a sole leader drastically going against the will of "the people" over an extended period of time. So realistically, the choice comes down to whether we value consistency more (in which case, we'd want to favor solutions that have a small N) or more directly empowering people with a democracy. Of course, you could try to do something that combines the two of them. You could elect a BDFL, but have PEPs go through a vote process first where they need to get a simple majority, and at which point the BDFL could approve or veto, and if they veto, then the voting body gets an additional chance to vote and if they're able to get a larger majority (2/3?) then they can override the BDFL's veto. That provides some protections from both a "design by committee" effect (since the BDFL can veto) but also provides very popular proposals a chance to pass even if the BDFL is against them. The big loss of that compromise is that you again, give up some of the consistency, since a large enough group of developers can still introduce an inconsistent vision and you remove the ability for the BDFL to accept unpopular but long term necessary PEPs (since they'd have to get a simple majority first).
_______________________________________________ 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/
