On Nov 29, 2012, at 12:16 PM, Martin v. Löwis wrote:

>1. I think that the PEP author has the final say as to what specific text
>goes into the PEP. Contributors shouldn't modify other people's PEP without
>consent from the author(s).
>
>2. This holds for all stages, including the Final stage. If the PEP author
>wants to clarify/elaborate, they may; if they don't feel like it, they don't
>need to (even if the implementation later deviates from the PEP).
>
>3. We should avoid to refer to PEPs for specification in the
>documentation. If there is a documentation issue proposing to update the PEP
>because it's referenced from the documentation, the right action should be to
>stop referencing it, and to incorporate the PEP text into the documentation
>(as needed).
>
>4. Even without the "In general" cop-out, I think the PEP is fine as
>written. It doesn't say (as Chris suggested in msg176603) that Final PEPs
>*should not* be modified, but that they *are not* modified. PEP 1 describes
>an ideal process, nobody should be surprised that the real world does not
>always follow the ideal. My biggest complaint about PEP 1 not being followed
>is the "PEP authors are responsible for collecting community feedback"
>requirement. Editing Final PEPs is absolutely no concern to me, since the PEP
>has already achieved what it was written for. So even if this rule was
>regularly ignored, I'd still continue to be a happy contributor to Python.

I agree with all of this.  Occasionally PEPs themselves may leave open the
possibility for future additions or changes.  Release schedule PEPs are one
example.  PEP 425 is another example, where the PEP seems like the logical
choice for registering future tags.

All this is fine IMHO, and doesn't need any further clarification in PEP 1.