This issue is to clarify the policy in PEP 1 regarding non-substantive changes to PEPs in the Final state (minor clarifications, rephrasings, etc).

Currently, PEP 1 says, "In general, Standards track PEPs are no longer modified after they have reached the Final state."

(from http://www.python.org/dev/peps/pep-0001/#pep-maintenance )

However, others have pointed out that minor clarifications and rephrasings are in fact allowed:

http://bugs.python.org/issue15990#msg176575

The updated wording should also state the policy or process regarding such changes (who is allowed to make them and whether and from whom approval is needed to make such changes, etc).

I don't think this needs clarification. The status quo is fine.

Are you saying that PEP 1 is correct and that Final PEPs should not be modified, or that the PEP isn't correct but that it shouldn't be modified?

If the latter, for someone new it's not clear whether minor clarifications are permitted and if so, how to go about making one.

I think Brett edited PEP 302 a decade after its acceptance.

On Nov 29, 2012, at 12:56 AM, Chris Jerdonek wrote:

>
>Currently, PEP 1 says, "In general, Standards track PEPs are no longer
>modified after they have reached the Final state."

I agree w/mvl.  This is still true, and it doesn't mean PEPs can't be modified
after reaching Final state.

Right, “in general” is good enough to capture what we do.  Chris, closing?

Okay, so in a comment to issue 15990, Ezio suggested that some clarifying changes to PEP 362 might be worth making.  How would I (or someone else) go about doing that?  Where would they begin?

I think this recent e-mail from Nick applies:

http://mail.python.org/pipermail/python-dev/2012-November/122525.html

By the way, I don't especially care if the clarification goes in the PEP itself or not.  What's more important is that it be documented *somewhere* (which could also be the devguide, for example).  My interest in knowing the process is genuine.

Once PEPs reach their final status, I view them basically done if there is more official docs. For instance, I updated PEP 302 because the import and importlib docs were not as thorough as they are now thanks to Barry. But now that we have proper docs I don't plan to muck with PEP 302 anymore. That being said, I wouldn't object if someone chose to put the effort into updating PEP 302 in the future, I just won't.

I think the gist here is that “in general” is good enough, given that there is unwritten consensus about what edits are possible in the developers’ heads.  Most of the time unwritten knowledge is not good, but (if I get what Martin and Barry mean correctly) for PEP rules this is fine.  We don’t want an over-detailed or inflexible process.

About the mail from Nick: it was talking about writing a new informational PEP, so I don’t see the link with final standards track PEPs.

FTR the reason I suggested to modify PEP 362 is that we are linking to it from the docs.  This means that people will go and read the PEP looking for clarifications, so the PEP should be clear.  In this regard I see the PEP (or at least the relevant section) as documentation, and given that it's about an aspect of Python that is not going to change any time soon, it makes sense to get it right and keep referencing the PEP.
This doesn't normally apply to most of the other PEPs, especially if what they proposed is now documented on docs.python.org.

(On a side note, I now noticed that the parameter kinds are also documented in http://docs.python.org/dev/library/inspect.html#inspect.Parameter.kind, so we could link to that instead of linking to the PEP.)

> I think the gist here is that “in general” is good enough, given that there is unwritten consensus about what edits are possible in the developers’ heads.

As I said, I'm okay with keeping the PEP as is (with "in general," etc) provided a clarification is documented elsewhere like in the devguide.  What I want to avoid are, as you say, there being "unwritten" rules about changing PEPs in the Final state.  (It was the general remarks about unwritten rules in Nick's e-mail that I felt were applicable.)

The written rules need not be overly-detailed or inflexible so long as they give newcomers without that common understanding a leg up on what to do.  It could be something as simple as "non-substantive changes to PEPs in the Final state should be treated like any other changes to the documentation" (or whatever the general process/criteria should be for such changes).

Yeah, I agree the "in general" in PEP 1 is enough of a caveat.

The unwritten rules in this particular case are that if something in a PEP is important enough to be permanently referenced, then it's important enough to be part of the language spec (either the main language reference or the stdlib reference), or else it should be a versioned informational PEP that gets replaced when updated (e.g. the WSGI spec, DB-API, packaging metadata etc).

There have been a few PEPs, most notably the import PEPs, where that wasn't possible because such docs didn't exist, and documenting the existing system would have taken so many caveats that nobody was ever willing to do it. So PEP 302 became the de facto documentation for the modular part of the import system. Now that we have real docs in the language reference for 3.3+, PEP 302 will finally be able fade into irrelevance as a normative document.

Now that the import case is resolved, I can't think of any Final PEPs where we're likely to break the rules any more, unless it's just to update them with a link to the normative docs.

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.

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.

Thanks for the feedback.  I will post here a devguide patch to include some of this information in the devguide.

With respect to editing final peps, I think this issue should be closed. The current PEP 1 statement accurately describes what we do, which is that in general we do not edit final peps. Moreover, Chris has not submitted a patch and I doubt anyone else knows what he thought he might add or where,

The only related question I have is in relation to Martin's point 3.
https://docs.python.org/devguide/documenting.html#id3
has the following:

pep
    A reference to a Python Enhancement Proposal. This generates appropriate index entries. The text “PEP number” is generated; in the HTML output, this text is a hyperlink to an online copy of the specified PEP.

Should we add something like "Such links should not be a substitute for properly documenting the language in the manuals."

This patch should close this languishing devguide issue. This patch adds wording suggested by Terry Reedy re: pep documentation reference to section 7.4.5 Inline markup (https://docs.python.org/devguide/documenting.html#id3).

The devguide covers the pep process and PEP 1 in section 20.1.2
(https://docs.python.org/devguide/langchanges.html?highlight=pep#pep-process).

Patch LGTM.

New changeset 0c4006b7c7ff by Berker Peksag in branch 'default':
Issue #16574: Clarify that once a PEP has implemented, it needs be
https://hg.python.org/devguide/rev/0c4006b7c7ff

Thanks!