On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby <p...@telecommunity.com> wrote: > At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote: >> >> On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby <p...@telecommunity.com> wrote: >> > At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: >> >> >> >> All fixed. >> > >> > Nope. I mean, sure, I checked in fixed PEP sources several hours ago, >> > but >> > python.org still doesn't show PEP 3333, or the updated version of PEP >> > 333. >> >> Seems Brett has fixed it. Both PEPs are now online. >> >> I wonder if it would make sense to change both from "Informational" to >> "Standard Track" ? > > From PEP 1: > > """ > There are three kinds of PEP: > * A Standards Track PEP describes a new feature or implementation for > Python. > * An Informational PEP describes a Python design issue, or provides > general guidelines or information to the Python community, but does not > propose a new feature. Informational PEPs do not necessarily represent a > Python community consensus or recommendation, so users and implementors are > free to ignore Informational PEPs or follow their advice. > * A Process PEP describes a process surrounding Python, or proposes a > change to (or an event in) a process. Process PEPs are like Standards Track > PEPs but apply to areas other than the Python language itself. They may > propose an implementation, but not to Python's codebase; they often require > community consensus; unlike Informational PEPs, they are more than > recommendations, and users are typically not free to ignore them. Examples > include procedures, guidelines, changes to the decision-making process, and > changes to the tools or environment used in Python development. Any meta-PEP > is also considered a Process PEP. > """ > > I don't think it qualifies as a Standards PEP under the above definitions. > I made it Informational originally because it's rather like the DB API > PEPs, which are Informational. > > I suppose we could say it's a Process PEP, or perhaps update PEP 1 to add a > new category (into which the DB API PEPs would also fall), or maybe just > tweak the above definitions a bit so that the Informational category makes > more sense.
Hm. I would rather extend the definition of Standards Track to include API standards that are important to the community even if they do not introduce a new feature for the language or standard library. WSGI and DB-API being the two most well-known examples but I wouldn't be surprised if there were others, possibly in the NumPy world. -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com