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

Barry Warsaw barry at python.org
Mon Apr 30 14:21:45 EDT 2018

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.

-Barry

-------------- 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>

More information about the Python-Dev mailing list