[Python-Dev] proposed amendments to PEP 1

[David Goodger]

[David Goodger]
>> I propose adding the following text:
 >>
>>     ...  The BDFL may also initiate a PEP review, first notifying the
>>     PEP author(s).

[Raymond Hettinger]
> Periodic updates to the parade-of-peps serves equally well.

Except that Guido doesn't have time to update the PEP Parade.  He told 
me so when I asked a few days ago.

> From these proposals and the annoucement earlier this week,
> I sense a desire to have fewer peps and to more rapidly get
> them out of the draft status.

Not quite.  The desire is not to cull the weak, but to promote the 
strong.  The desire is to change already-implemented and 
implicitly-accepted PEPs to from "Status: Draft" to "Status: Accepted" 
or "Status: Final".  See the "Accepted PEPs?" thread from a few days 
ago; 9 "Draft" but already-implemented-for-2.3 PEPs were identified. 
Their status lines ought to be changed, but the wording as written 
implies that Guido and the PEP editors have to wait for authors to ask 
for a review.  We should be able to be more proactive.

New proposed addition:

     ...  For PEPs that are pre-determined to be acceptable (e.g.,
     their implementation has already been checked in) the BDFL may
     also initiate a PEP review, first notifying the PEP author(s)
     and giving them a chance to make revisions.

It is implied that Guido himself doesn't necessarily do all the 
notifying or initiating, but may delegate to his loyal serfs. ;-)

 > If someone wants
 > to do a write-up and weather the ensuing firestorm, that is
 > enough for me.  If it has to sit for a few years before becoming
 > obviously good or bad, that's fine too.
 >
 > Also, some ideas need time.

Good points; I agree completely.  I have no problem leaving doomed (or 
currently perceived as doomed) PEPs to remain in limbo until the 
author(s) choose to seal their fate.

>> For a PEP to be accepted it must meet certain minimum criteria. It
>> must be a clear description of the proposed enhancement. The 
>> enhancement must represent a net improvement. The implementation, 
>> if applicable, must be solid and must not complicate the 
>> interpreter unduly. Finally, a proposed enhancement must be 
>> "pythonic" in order to be accepted by the BDFL. (However, 
>> "pythonic" is an imprecise term; it may be defined as whatever is 
>> acceptable to the BDFL. This logic is intentionally circular.)

Clarification: this paragraph addresses a completely separate issue than 
the proposed addition above.  I have sensed some confusion as to what 
constitutes an acceptable PEP, and a hand-waving blurb giving a vague 
definition seems useful.  Of course, it would be great if we could make 
the text more precise, but vagueness may have value here.  Comments on 
the wording are welcome.

> IOW, I like the process as it stands and am -1 on the 
> amendment.  It should be up to the pep author to 
> decide when to stick his head in the guillotine to
> see what happens :)

What's your opinion now, post-clarifications?  Please treat the two 
parts separately.

-- David Goodger