[python-committers] And Now for Something Completely Different

Donald Stufft donald at stufft.io
Fri Jul 20 14:30:58 EDT 2018

> On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstinner at 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

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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180720/dbaae407/attachment.html>

More information about the python-committers mailing list