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

Petr Viktorin encukou at gmail.com
Thu Oct 4 03:45:41 EDT 2018


On 10/3/18 2:12 PM, 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.
> 
> I am well aware of the current governance issues, but several people 
> have mentioned that the BDFL-Delegate process can still continue for 
> now. I created a PR for the peps repository at 
> https://github.com/python/peps/pull/797
> 

Hello,
I don't think it's formally possible to do that now, but the following 
from elsewhere in the thread does make sense:

Antoine Pitrou:
> Consensus would obviously work (if no-one opposes the proposed person,
> then surely we don't need an elaborate governance model to decree that
> said person can become the PEP delegate, no?).

Yes, it would feel very silly to have consensus and not be able to act 
on it. But without a governance (and approval process) it's hard to 
*ensure* we have consensus where all relevant voices have been heard.

On the other hand, I don't agree with Nick Coghlan here:
> In this case, I'd consider it unlikely for either the PEP delegate appointment or any decisions about the PEP itself to be overturned - while it's a complex topic that definitely needs to go through the PEP process in order to work out the technical details, it isn't especially controversial in its own right (the most controversial aspect is whether it needs a new C level slot or not, and the PEP should clearly lay out the pros and cons of that)

PEP 580 *is* controversial -- there's the competing PEP 576 by Mark 
Shannon, who hasn't commented on this recently. Either would be an 
improvement, but choosing between them is a hard trade-off.
I'll leave technical stuff to another thread and concentrate on the 
process here.

When I'm happy with the PEP *and* if Mark says he's OK with it, I'll 
post a summary to Python-dev & Discourse with a special focus on the 
cons (e.g. the size increase of classes, which will affect everyone). If 
there are no "-1"s on the PEP itself or on the way it's discussed, let's 
treat PEP 580 as *provisionally* accepted, to be reverted if the new 
governance doesn't ratify it.

If there is no consensus, we'll need to wait for the new governance to 
decide.


More information about the Python-Dev mailing list