Nick Coghlan added the comment: 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. ---------- components: +Devguide -Documentation _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16574> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
