[Python-Dev] PEP 1, PEP Purpose and Guidelines

[Aahz]

All right, here are some suggested changes.  Actual suggestions are
indented; commentary and meta-information is not indented.

On Mon, Jul 29, 2002, Barry A. Warsaw wrote:
>
> Kinds of PEPs
> 
>     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.  Informational PEPs do not necessarily represent a Python
>     community consensus or recommendation, so users and implementors
>     are free to ignore informational PEPs or follow their advice.

Add:

    Some informational PEPs become Meta-PEPs that describe the workflow
    of the Python project.  Project contributions that fail to follow the
    prescriptions of Meta-PEPs are likely to be rejected.

>     If the PEP editor approves, he will assign the PEP a number, label
>     it as standards track or informational, give it status 'draft',
>     and create and check-in the initial draft of the PEP.  The PEP
>     editor will not unreasonably deny a PEP.  Reasons for denying PEP
>     status include duplication of effort, being technically unsound,
>     not providing proper motivation or addressing backwards
>     compatibility, or not in keeping with the Python philosophy.  The
>     BDFL (Benevolent Dictator for Life, Guido van Rossum) can be
>     consulted during the approval phase, and is the final arbitrator
>     of the draft's PEP-ability.

Substitute:

    If the PEP editor approves, he will assign the pre-PEP a number,
    label it as standards track or informational, give it status 'draft',
    and create and check-in the initial draft of the PEP.  The PEP editor
    will not unreasonably deny a pre-PEP.  Reasons for denying PEP status
    include duplication of effort, being technically unsound, not
    providing proper motivation or addressing backwards compatibility, or
    not in keeping with the Python philosophy.  The BDFL (Benevolent
    Dictator for Life, Guido van Rossum) can be consulted during the
    approval phase, and is the final arbitrator of the draft's
    PEP-ability.  Generally speaking, if a pre-PEP meets technical
    standards, it will be accepted as a PEP to provide a historical
    record even if likely to be rejected (see the later section on
    rejecting a PEP).

(This is to clarify the distinction between denying a pre-PEP and
rejecting a PEP later in the process.)

>     A PEP can also be `Rejected'.  Perhaps after all is said and done
>     it was not a good idea.  It is still important to have a record of
>     this fact.

Add (not sure whether it should be a separate paragraph):

    The PEP author is responsible for recording summaries of all
    arguments in favor and opposition.  This is particularly important
    for rejected PEPs to reduce the likelihood of rehashing the same
    debates.

>     6. Rationale -- The rationale fleshes out the specification by
>        describing what motivated the design and why particular design
>        decisions were made.  It should describe alternate designs that
>        were considered and related work, e.g. how the feature is
>        supported in other languages.
> 
>        The rationale should provide evidence of consensus within the
>        community and discuss important objections or concerns raised
>        during discussion.

I'm thinking we should add a section 9) titled "Discussion summary" to
make it clearer that the PEP author is required to include this
information.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

Project Vote Smart: http://www.vote-smart.org/