osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580


> On 3 Oct 2018, at 23:10, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> On 10/3/2018 8:12 AM, Jeroen Demeyer wrote:
>> Hello,
>> I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, titled "The C call protocol". He has co-authored several PEPs (PEP 394, PEP 489, PEP 534, PEP 547, PEP 573), several of which involve extension modules.
>> Petr has agreed to become BDFL-Delegate for PEP 580 if asked. Also Antoine Pitrou, INADA Naoki and Nick Coghlan have approved Petr being BDFL-Delegate.
> 
> To me, three experienced core devs approving of a 4th person as PEP-examiner is sufficient to proceed on a CPython implementation proposal.  I don't think we need to be paralyzed on this.

What you're saying is sensible, the team is small enough and tightly knit that we trust each other. However, trust is not the point. It's about clear expectations and avoiding anarchy. As Nick points out elsewhere, circumventing the lack of governance by "asking a few friends" on the core team creates a need for the new leadership to ratify those changes. Speaking frankly, it would be a major shit show if any of those changes were to be reverted. As the release manager of this version of Python, can I ask you please not to risk this?

Ironically, the governance model I am championing is one that would closely resemble what you're describing. A community of experts, no kings: https://discuss.python.org/t/pep-8012-the-community-model/156/

So it's really not that I disagree with you, I do. It's not that I don't trust Petr, I do. It's that I believe the core team needs to formalize how they want the project to proceed before they go run approving PEPs.


> And indeed, when it comes to sub-PEP C-API changes, we seem not to be.

Any sub-PEP changes are fair game at the moment.


> This change, if made, should be early in the cycle for the next version, rather than landing just before the first beta.

There is little to be gained in landing "early in the cycle" when alpha releases are not widely available anywhere and there is a 6-month long beta period. More importantly, using "we need to land fast" as an argument to rush things in is self-defeating.


> A language syntax-change proposal would be something else.

Anything that is big enough to require a PEP is by definition a substantial change and controversial that way. As somebody else here points out, there is even a competing PEP. That sounds controversial to me.

- ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20181004/143997ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-dev/attachments/20181004/143997ab/attachment.sig>