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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4