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

[Petr Viktorin]

On 10/4/18 1:38 PM, Łukasz Langa wrote:


On 3 Oct 2018, at 23:10, Terry Reedy > 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.


Łukasz, as the release manager for 3.8 you're the closest we have to an 
authority, so I defer to your judgment. No PEPs can currently be accepted.



Anyway, even if I was a *-delegate here, I would need to hear Mark 
Shannon's opinion on the PEP. Convincing him will probably be harder 
than convincing me.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Łukasz Langa]

> On 4 Oct 2018, at 08:14, Nick Coghlan  wrote:
> 
> I was figuring we could treat it as a caretaker mode governance: anything we 
> do before the new governance model is formalised is subject to ratification 
> by the new council members (or the new BDFL if that option ends up being 
> chosen).

Unless we end up with neither a BDFL nor a council... *cough* PEP 8012 *cough* 
;-)

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Łukasz Langa]

> On 3 Oct 2018, at 23:10, Terry Reedy  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.

- Ł



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Petr Viktorin]

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.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

On 2018-10-03 23:27, Guido van Rossum wrote:

IMO changes to the C API should be taken just as seriously -- the
potential for breaking the world is just about the same (since most
serious Python applications use C extensions that risk breaking).


Of course we are taking this seriously. I want this to be taken as 
seriously as any other PEP and any other BDFL-Delegate appointment in 
the past.


To be clear: I'm not trying to rush my PEP though. It has been discussed 
and I have made changes to it based on comments. In fact, this is the 
second PEP with the same subject, I withdrew the first one, PEP 575. At 
some point in the past I asked one person to become BDFL-Delegate but he 
did not answer. And now recently Petr Viktorin made some insightful 
comments on it, so I asked him and he agreed.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

On 2018-10-03 18:55, Barry Warsaw wrote:

Correct.  It’s entirely possible that the different governance models will have 
different ways to pick delegates.


And how does that affect *today*'s decision? The new governance model 
will only take effect 1 January (assuming that everything goes as planned).


As long as there is no new governance model yet, can't we just continue 
the PEP 1 process which has worked for many years? I know that we cannot 
literally apply PEP 1 because there is no BDFL, but we can certainly 
continue the spirit of PEP 1 if the other core developers agree with the 
BDFL-Delegate.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

On Thu., 4 Oct. 2018, 4:12 am Antoine Pitrou,  wrote:

> On Wed, 3 Oct 2018 22:51:24 +0900
> INADA Naoki  wrote:
> > 2018年10月3日(水) 21:24 Jeroen Demeyer :
> >
> > > Hello,
> > >
> > >
> > > I am well aware of the current governance issues, but several people
> > > have mentioned that the BDFL-Delegate process can still continue for
> > > now.
> >
> >
> > Really?
> > I don't know process to assign BDFL-delegate without BDFL.
>
> That's probably why we should call it "PEP-delegate" :-)
>
> 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?).
>

I was figuring we could treat it as a caretaker mode governance: anything
we do before the new governance model is formalised is subject to
ratification by the new council members (or the new BDFL if that option
ends up being chosen).

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)

Cheers,
Nick.



> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

Well, it's not my call any more, so I'll happily stop arguing.

On Wed, Oct 3, 2018 at 3:19 PM Terry Reedy  wrote:

> On 10/3/2018 5:27 PM, Guido van Rossum wrote:
> > On Wed, Oct 3, 2018 at 2:13 PM Terry Reedy  > > wrote:
> >
> > A language syntax-change proposal would be something else.
> >
> >
> > IMO changes to the C API should be taken just as seriously -- the
> > potential for breaking the world is just about the same (since most
> > serious Python applications use C extensions that risk breaking).
>
> I agree.  My observation is that PEP-delegates have taken their
> responsibility *very* seriously, and I think that the evidence is that
> Petr would.  If you think otherwise, please explain.  On reason for a
> serious examination to start now is to allow adequate time.
>
> The difference I was referring to is the philosophical basis of and
> technical evaluation skill needed for a decision.  I feel competent to
> opine on syntax proposals, but not on technical details of CPyython
> calls.  Moreover, as long as an internal change does not break anything,
> and at least does not hinder writing C extensions, I have little reason
> to care, whereas syntax changes will affect me, even if they are 'good'
> changes.
>
> --
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

On 10/3/2018 5:27 PM, Guido van Rossum wrote:
On Wed, Oct 3, 2018 at 2:13 PM Terry Reedy > wrote:


A language syntax-change proposal would be something else.


IMO changes to the C API should be taken just as seriously -- the 
potential for breaking the world is just about the same (since most 
serious Python applications use C extensions that risk breaking).


I agree.  My observation is that PEP-delegates have taken their 
responsibility *very* seriously, and I think that the evidence is that 
Petr would.  If you think otherwise, please explain.  On reason for a 
serious examination to start now is to allow adequate time.


The difference I was referring to is the philosophical basis of and 
technical evaluation skill needed for a decision.  I feel competent to 
opine on syntax proposals, but not on technical details of CPyython 
calls.  Moreover, as long as an internal change does not break anything, 
and at least does not hinder writing C extensions, I have little reason 
to care, whereas syntax changes will affect me, even if they are 'good' 
changes.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

On Wed, Oct 3, 2018 at 2:13 PM Terry Reedy  wrote:

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

IMO changes to the C API should be taken just as seriously -- the potential
for breaking the world is just about the same (since most serious Python
applications use C extensions that risk breaking).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

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.  And indeed, 
when it comes to sub-PEP C-API changes, we seem not to be.  This change, 
if made, should be early in the cycle for the next version, rather than 
landing just before the first beta.


A language syntax-change proposal would be something else.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

On Wed, 3 Oct 2018 22:51:24 +0900
INADA Naoki  wrote:
> 2018年10月3日(水) 21:24 Jeroen Demeyer :
> 
> > Hello,
> >
> >
> > I am well aware of the current governance issues, but several people
> > have mentioned that the BDFL-Delegate process can still continue for
> > now.  
> 
> 
> Really?
> I don't know process to assign BDFL-delegate without BDFL.

That's probably why we should call it "PEP-delegate" :-)

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

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

On Oct 3, 2018, at 08:06, Łukasz Langa  wrote:
> 
>> On 3 Oct 2018, at 15:51, INADA Naoki  wrote:
>> 
>> Really?
>> I don't know process to assign BDFL-delegate without BDFL.
> 
> My understand is that accepting *any* PEP by anyone is out of the question 
> until the governance situation gets resolved. That's the only reason why PEP 
> 544 is not yet accepted for example.

Correct.  It’s entirely possible that the different governance models will have 
different ways to pick delegates.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

On 2018-10-03 17:06, Łukasz Langa wrote:

That's the only
reason why PEP 544 is not yet accepted for example.


Did you actually try to get PEP 544 accepted or to appoint a 
BDFL-Delegate? I don't find any discussions about PEP 544 after the 
stepping down of the BDFL.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

On 2018-10-03 17:12, Wes Turner wrote:
> AFAIU, there is not yet a documented process for BDFL-delegate assignment.

PEP 1 says:

"""
However, whenever a new PEP is put forward, any core developer that
believes they are suitably experienced to make the final decision on
that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for
that PEP. If their self-nomination is accepted by the other core
developers and the BDFL, then they will have the authority to approve
(or reject) that PEP.
"""

I know that it says "core developers and the BDFL". However, if the core
developers agree that Petr can become BDFL-Delegate, I don't see why
that wouldn't be possible.


Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Wes Turner]

On Wednesday, October 3, 2018, INADA Naoki  wrote:

>
> 2018年10月3日(水) 21:24 Jeroen Demeyer :
>
>> Hello,
>>
>>
>> I am well aware of the current governance issues, but several people
>> have mentioned that the BDFL-Delegate process can still continue for
>> now.
>
>
> Really?
> I don't know process to assign BDFL-delegate without BDFL.
>

AFAIU, there is not yet a documented process for BDFL-delegate assignment.

There's this in the devguide; which links to PEP1:

"20.2. PEP Process¶"
https://devguide.python.org/langchanges/#pep-process
https://github.com/python/devguide/blob/master/langchanges.rst


And PEP 1:

"PEP 1 -- PEP Purpose and Guidelines"
  "PEP Workflow"
https://www.python.org/dev/peps/pep-0001/#pep-workflow
  "PEP Editors"
https://www.python.org/dev/peps/pep-0001/#pep-editors
  "PEP Editor Responsibilities & Workflow"
https://www.python.org/dev/peps/pep-0001/#pep-editor-responsibilities-workflow

https://github.com/python/peps/blob/master/pep-0001.txt

And the devguide has a list of experts:
https://devguide.python.org/experts/


Maybe PEP1 is the place to list current BDFL-Delegates
(in addition to in the PEP metadata as in the OT PR:
python/peps#797
"PEP 580: Petr Viktorin as BDFL-Delegate"
)?


Not to bikeshed, but is BDFL-Delegate still the current term because that's
what's in all the other PEPs' metadata?


>
> This PEP is mainly for third party tools.
> I want to get much feedback from them before new APIs become stable (e.g.
> 3.8b1)
>
> So I want this PEP is approved (or
> Provisionally Accepted) and reference implementation is merged as fast as
> possible.
>
> Regards,
>
>>
>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Łukasz Langa]

> On 3 Oct 2018, at 17:06, Łukasz Langa  wrote:
> 
> My understand is

臘‍♂️

...and no ability to edit to correct it. It's like this forever now, my grand 
children will ridicule me for this.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Łukasz Langa]

> On 3 Oct 2018, at 15:51, INADA Naoki  wrote:
> 
> 
> 2018年10月3日(水) 21:24 Jeroen Demeyer  >:
> Hello,
> 
> 
> I am well aware of the current governance issues, but several people
> have mentioned that the BDFL-Delegate process can still continue for
> now.
> 
> Really?
> I don't know process to assign BDFL-delegate without BDFL.

My understand is that accepting *any* PEP by anyone is out of the question 
until the governance situation gets resolved. That's the only reason why PEP 
544 is not yet accepted for example.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[INADA Naoki]

2018年10月3日(水) 21:24 Jeroen Demeyer :

> Hello,
>
>
> I am well aware of the current governance issues, but several people
> have mentioned that the BDFL-Delegate process can still continue for
> now.


Really?
I don't know process to assign BDFL-delegate without BDFL.


This PEP is mainly for third party tools.
I want to get much feedback from them before new APIs become stable (e.g.
3.8b1)

So I want this PEP is approved (or
Provisionally Accepted) and reference implementation is merged as fast as
possible.

Regards,

>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Wes Turner]

On Wednesday, October 3, 2018, 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


+1. Are we doing upvotes on the mailing list or on the GitHub PR and/or
issue now?

"[Python-ideas] PEPs: Theory of operation"
https://markmail.org/thread/zr4o6l7ivnj4irtp

"""
Process suggestions that could minimize non-BDFL's BDFL legwork:

[...]

* Use GitHub reactions for voting on BDFL delegates, PEP final approval,
and PEP sub issues?
  * Specify a voting deadline?
  * How to make a quorum call?
  * Add '@core/team' as reviewers for every PEP?


* Link to the mailing list thread(s) at the top of the PR
  * [ ] Add unique message URLs to footers with mailman3


* What type of communications are better suited for mailing lists over PEP
pull-requests and PEP code reviews?
[The original thread is probably a better place to discuss PEP process
going forward]
"""


>
>
> Cheers,
> Jeroen Demeyer.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.
> turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com