This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients barry, brett.cannon, chris.jerdonek, docs@python, eric.araujo, ezio.melotti, goodger, loewis, ncoghlan
Date 2012-11-29.05:49:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1354168142.11.0.326883937368.issue16574@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-11-29 05:49:02ncoghlansetrecipients: + ncoghlan, loewis, barry, brett.cannon, goodger, ezio.melotti, eric.araujo, chris.jerdonek, docs@python
2012-11-29 05:49:02ncoghlansetmessageid: <1354168142.11.0.326883937368.issue16574@psf.upfronthosting.co.za>
2012-11-29 05:49:02ncoghlanlinkissue16574 messages
2012-11-29 05:49:01ncoghlancreate