[Python-Dev] [Web-SIG] WSGI is now Python 3-friendly (original) (raw)

P.J. Eby pje at telecommunity.com
Tue Sep 28 05:34:26 CEST 2010

At 05:41 PM 9/27/2010 -0700, Guido van Rossum wrote:

On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby <pje at 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 <pje at 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.

Well, one of the tradeoffs here is that Informational track allows something to grow into a solid standard without also having to pass the same level of up-front scrutiny and commitment that a Standards track item does. I rather doubt that either the DBAPI or WSGI would've passed that scrutiny in early days, and the "free to ignore" part means that there's a lot less pushback on the minor points than generally occurs with Standards track PEPs.

So, I'd hate for us to lose out on the next DBAPI or WSGI due to an implied pressure of needing to get it right in the first place. (Indeed, I think we need more Informational PEPs -- in retrospect there was probably some point at which I should have done some relating to setuptools and eggs and such.)

Overall, though, I supposed there's no problem with promoting Final Informational PEPs to Standards, unless it creates an expectation that Informational PEPs will become Standards and they thus end up being debated in the same way anyway. (Of course, if it generally takes five or six years before an Informational PEP usually gets promoted, this is unlikely to be a major worry.)

More information about the Python-Dev mailing list