[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Superseding PEPs (was Re: PEP 394: Allow the `python` command to not be installed (and other minor edits))

On Apr 30, 2018, at 06:36, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Instead of editing old PEPs, would it make sense to write a new one
> which replaces the old one?

As a general rule, at least the way I think about it, Informational PEPs can mostly be updated inline, evolving with new insights as we go along.  As Nick points out, this gives folks a consistent place to read our current recommendations and guidelines.  They?re informational so almost by definition contemporaneous.

Standards Track PEPs on the other hand shouldn?t be changed once finalized, except around the margins, e.g. typos, updated URLs, that kind of thing.  These PEPs should capture the discussion and design at the time that the feature is solidified and lands; they do *not* serve as latest up-to-date documentation on the feature.  If the feature changes or becomes obsolete in future versions of Python, a new PEP should be written to supersede the old PEP.  We even have an official `Superseded` Status value, and a `Superseded-By` header.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180430/f1bd3a5d/attachment.sig>