[Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

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