[Python-Dev] Proposal: Update PEP 1 to allow an explicit "Provisional" status for PEPs

[Nick Coghlan]

On 18 December 2014 at 08:10, Barry Warsaw <barry at python.org> wrote:
> On Dec 18, 2014, at 06:57 AM, Nick Coghlan wrote:
>
>>However, I'd be happier if we could communicate that status more
>>explicitly through the PEP process, especially as I think such a
>>capability would be useful more generally as we move towards
>>implementing metadata 2.0 and potentially other enhancements for pip
>>7+ next year.
>>
>>If folks are OK with this idea, I'll go ahead and make the appropriate
>>changes to PEP 1 and the PEP index generator. I'm also happy to file a
>>tracker issue, or write a short PEP, if folks feel making such a
>>change requires a little more formality in its own right.
>
> Hi Nick.  What specific changes do you propose to PEP 1 and/or the PEP
> process?   FWIW, if they are fairly simple, then I think a tracker issue with
> at least the PEP 1 authors nosied would be fine.

Yeah, good point - I'll want a tracker issue regardless to host the
Reitveld review. Filed at http://bugs.python.org/issue23077

My current thinking is that for future PEPs relying on PEP 411 to
include a provisional API directly in the standard library, the
Provisional state would effectively replace the Accepted state:

Draft -> Provisional (with PEP 411 disclaimer on the implementation)
-> Final (PEP 411 disclaimer removed)

For interoperability standards track PEPs, I'd propose tweaking their
flow to allow the use of the "Active" state, and stop using
Accepted/Final entirely:

Draft -> Provisional -> Active (-> Superseded)

However, looking at that, I'm starting to wonder if the PEPs like
WSGI, the database API, the crypto API, and the packaging PEPs should
be pulled out into a new PEP category (e.g. "Standards Track
(Interoperability)") to reflect the fact that they're defining a
protocol, not just a particular standard library API.

At the moment, we have an odd split where many of those are listed
under "Other Informational PEPs" (together with things like the
instructions for doing releases), while the packaging interoperability
PEPs are Standards Track PEPs currently listed under "Accepted PEPs".

I think the next step would be for me to come up with a draft patch,
and then if we think it needs a PEP for broader review (which now
seems likely to me), we can decide that on the tracker issue.

Cheers,
Nick.

P.S. You'd think I'd have learned my lesson by now when it comes to
pulling on the thread that is PEP 1, but apparently not :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia