[python-committers] And Now for Something Completely Different

[Victor Stinner]

Hi Ethan,

Thanks for your feedback!

2018-07-20 2:51 GMT+02:00 Ethan Furman <ethan at stoneleaf.us>:
>> 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.

In that case,  I would prefer that people abstain from voting on this
mailing list (I'm talking about "+1" emails), before a formal and well
defined PEP is written ;-)


> 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,

Hum, first I would like to have better statistics on the number of
active core developers. On Stéphane Wirtel statistics on pull
requests, the number of active core developers was closer to 34...

Would you mind to elaborate? How would enum be inconsistent without
the BDFL work?

> and still there were about 1,000 emails over several threads

Honestly, I don't recall the discussion on the enum module. What do
you mean by this large number of emails?

People are free to send emails, but at the end, a vote would occur on
a proper PEP, not on emails.

Let me try to guess what you mean. Do you mean that a 50%+1 majority
would be impossible to reach because each core developer had a
different taste on how enum should look like?

What I saw in PHP RFC is that sometimes there are multiple votes on a
single RFC, to choose between alternatives (translation for Python:
replace RFC with PEP :-)). A recent example:

  https://wiki.php.net/rfc/array_key_first_last

The RFC proposed to add array_key_first/last()" and
array_value_first/last(). The array_value variant was controversial
and so has been voted separately. There was a corner value for values:
a value can really be null, whereas the RFC proposes to also return
null to signal an error. This case doesn't occur with keys, since
using null as a key is automatically replaced with an empty string:
it's possible to distinguish null as an error. They decided to approve
array_key_first()/last() but reject array_value_first()/last(), which
IMHO is a wise choice :-)

For enum, if you are talking about the two proposed alternatives "Not
having to specify values for enums" and "Using special names or forms
to auto-assign enum values", I guess that separated votes could be
used: one vote for the main idea "having an Enum type", and a vote on
the variants. The PEP author (and maybe an expert would him them to
drive the PEP) would decide which votes are worth it.


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

Sorry, I don't understand what is wrong with this PEP. If I recall
correctly, all core developers were in favor of adding back this
feature to Python 3, no?

I recall that I started to write a PEP 460, but Antoine wanted to
"modify" it. In fact, he basically rewrote it from scratch, so I asked
him to remove my name from it :-)

Then you wrote a competitor PEP. At the end, your PEP won.

I don't see how bytes % args is a good example of the need of a BDFL
to keep Python consistent. Would you mind to elaborate? Do you have
that having two PEPs in a competition goes against the principle of
voting?


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

Hum, I don't recall well this discussion. If I recall correctly, the
consensus quickly agreed to reject the PEP. Most people already
disliked the PEP on python-ideas, no... I'm not sure of that. At
least, I disliked the PEP since its start :-)

What do you mean by "not sure if it would have been accepted by majority vote"??


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

Joker! I will not comment that one. I don't have enough perspective on it yet.


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

I agree that an author can be confused when two different core
developers ask to make two opposite changes. This is where an expert
can help the author to drive the discussion and help the author to
make choices.

To formalize a little bit more, I would identify 3 groups: PEP authors
(usually an individual), group who help authors to write the PEP and
drive the discussion, group who vote (all core devs) at the end.

I guess that the group helping the authors is supposed to like the
proposed change, but I'm not sure that it's mandatory. It's like an
advocate who is supposed to help their client even if their client
killed someone ;-)

If you want a recent example, on the PEP 572, Guido and Tim were
strong supporters of the PEP and they helped a lot Chris to refine his
PEP. At the end, they even decide to become co-authors.


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

Sorry, what does BDFOP stand for?

I saw people writing "mandatory votes" in a different thread. I don't
see why anyone would be forced to vote on PEPs :-) (I'm not talking
here about this very specific case of deciding a new governance for
Python.)

I prefer to abstain me from commenting PEPs in some areas like typing
or distutils, since they are out of my interest area and I don't feel
that I would add anything useful. I love that other experts who have a
stronger background in these topics than me are able to provide good
feedback to drive the discussion.


Hum. Let me try to explain my point differently. Currently, some
people don't read PEPs just because at the end, only the single BDFL
vote counts. What's the point of spending hours (if not days) on
reading a long PEP and the long discussion on mailing lists, if your
count doesn't count? Now imagine that all votes count. I expect that
people will spend more time on reading carefully each PEP and follow
more closely discussions since they will be de facto more involved in
the decision process.

By the way, PHP votes on RFC votes is public. One advantage is that it
forces voters to vote "seriously", since later someone can ask them
why they voted like that :-)

Are you sure that all core developers would have have the knee
reaction of rejecting the PEP 572 if their vote really counts? On
python-committers, I opened a *poll* on the PEP 572. The meaning is
very different from a real vote where your voice really counts.

Another way to explain it. It's really hard to force volunteers to
work for free... In a regular job, IMHO a good way to involve workers
is to give them more responsibilities.

I already saw this issue on reviews. I read someone saying that they
don't review pull requests since only core developers can merge
changes, so what's the point of commenting? If you take the point of
view of the core developer: merging a pull request means that it
becomes your pet for life, you will have to clean up its shit for its
whole life... So core developers feel more responsible when commenting
pull requests.

And now we ask regular contributor to do more reviews? I'm not sure
that it works. If you want someone to do more review, IMHO you should
give them the right to merge a PR. Suddenly, people are more careful
on reviews :-)


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

See my previous point: you are not asked to vote on all PEPs. You are
free to abstain from voting.

"Time is at a premium." is very true in open source software where
almost everybody is volunteer. This is why I consider that a BDFL or a
council is not sustainable regarding the popularity of Python and the
pressure on accepting changes.

A BDFL was definitively a good choice 20 years ago, when Python was
new and little used. Time changed. Python became #1 programming
language in many area. They are million of users. We all feel the
pressure of users who expect stability (this is partially why Python
2.7 is still very popular nowadays). IMHO a single BDFL can no longer
handle the high number of PEPs nor the high traffic of python-ideas
and python-dev lists. Moreover, since it has been written that no core
developer is legitimate to replace BDFL, I expect even stronger
criticism on the Internet against "unpopular" accepted changes...

These problems go away when you replace a single BDFL with a
collective decision. Dozens of core developers scale and accumulate
skills.

Victor