[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

Raymond Hettinger wrote:

I'm not sure it would have filtered out anything except an April Fools pep.

That one was its own reward. :-) -- David Goodger

Skip Montanaro wrote:

I'd like to move PEP 305 (CSV) along and intend to bring the text up-to-date w.r.t. the current implementation, however the code which implements CSV reading and writing doesn't currently handle Unicode. Given that there is a module checked into CSV,

CVS?

what should the PEP's status be, "draft" or "accepted" or something else?

"Accepted" for now, becoming "Final" when the implementation is finished. Assuming my first proposed PEP 1 amendment is okayed, Guido has already indicated that PEP 305 is to be accepted. -- 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

Raymond Hettinger wrote:

I'm not sure it would have filtered out anything except an April Fools pep.

That one was its own reward. :-) -- David Goodger

Skip Montanaro wrote:

I'd like to move PEP 305 (CSV) along and intend to bring the text up-to-date w.r.t. the current implementation, however the code which implements CSV reading and writing doesn't currently handle Unicode. Given that there is a module checked into CSV,

CVS?

what should the PEP's status be, "draft" or "accepted" or something else?

"Accepted" for now, becoming "Final" when the implementation is finished. Assuming my first proposed PEP 1 amendment is okayed, Guido has already indicated that PEP 305 is to be accepted. -- David Goodger