[python-committers] Transfer of power

[Tim Peters]

[Tim]

> Guido's most visible (well, to us committers) BDFL role has been in
> "yes/no", "go/nogo" language/library design questions, which don't even
> overlap with the PSF's proper concerns.
>
> But I'm not sure it's fully appreciated just how active Guido has been in
> those at times.  The "accepted/rejected" at the end of major PEPs is just a
> small part of that.  Along the way, e.g., it's been pretty common to see a
> "Save your breath.  That's not going to happen." from Guido to end a
> distracting alternative (sub)proposal persistently promoted by one (or a
> few) very active and/or loquacious posters.
>
> [Jack Jansen]


> This is a very good point. And it is a role that is not “formally encoded”
> anywhere, and one that I think cannot be formally encoded.
>
> And actually I wonder whether this role could be fulfilled by any
> person/committee/procedure other than Guido himself. Which means that in
> future we should prepare for doing without this role. Which will lead to
> more contentious issues being put in front of the
> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going
> to happen.
>
>
> I'm not quite as hopeless ;-)  Most notions on python-ideas are dropped
voluntarily, after it's clear that they generate little interest - or
massive hostility ;-)

For one that proceeds to a preliminary PEP, I think it would be wise for
the Elders (whatever it's called) to appoint a BDFL-workalike for that
specific PEP.  Which may or may not be an Elder.  That person would need to
commit to staying current with the PEP's progress, and would have final
"yes/no", "this/that", ...  authority on all the design decisions on the
way to polishing the PEP.  But not the final accept/reject decision (if the
PEP survives that long).

That would do more than "just" provide a BDFL-workalike for the PEP, it
would also provide a kind of mentor for PEP writers sometimes pretty
clueless about what the community expects from a PEP.

It wouldn't provide a consistent design vision _across_ PEPs, but would at
least leave each PEP coherent on its own in _some_ experienced developer's
mind.  Leaving the final accept/reject to someone else is, in part, a nod
to that even a self-coherent PEP may be best rejected for clashing with a
broader vision.

With a bit of luck, PEP authors and their BDFL-workalikes will come to
despise each other so swiftly that no PEP will ever finish again ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180716/fbf3990a/attachment-0001.html>