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

[Guido van Rossum]

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.

-- 
--Guido van Rossum (python.org/~guido)