Pre-PEP Proposal: Codetags

[A.M. Kuchling]

On Thu, 11 Aug 2005 08:47:37 +0200, 
	Martin v. Löwis <martin at v.loewis.de> wrote:
> I think you somewhat misunderstood the purpose of the PEP process.
> This is meant primarily for enhancements to Python (the language
> and its library), ...

PEP 0 disagrees:

     PEP stands for Python Enhancement Proposal.  A PEP is a design
     document providing information to the Python community, or describing
     a new feature for Python.  The PEP should provide a concise technical
     specification of the feature and a rationale for the feature.

     ...
     
     There are two kinds of PEPs.  A Standards Track PEP describes a new
     feature or implementation for Python.  An Informational PEP describes
     a Python design issue, or provides general guidelines or information
     to the Python community, but does not propose a new feature.

Most of PEP 0 is concerned with describing the workflow for Standards Track
PEPs, of course, but I guess there's not much to say for informational PEPs.
("Publish your PEP.  Eventually, freeze the PEP and stop making changes to it."
would be about the sum of it.)

I think we need to encourage writing detailed specifications of interfaces
for the community's use, such as the WSGI interface (PEP 333, IIRC), so
using the PEP repository for this purpose is a good idea.  If such things
are deemed off-topic for PEPs, then I think we should have a separate set of
documents for this (perhaps the suggested PEEPS: Python Environment
Enhancement Proposals).  

--amk