On Apr 30, 2018, at 06:36, Nick Coghlan <ncogh...@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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
