[Web-SIG] PEP 444 != WSGI 2.0

[Guido van Rossum]

On Sun, Jan 2, 2011 at 12:14 PM, Alice Bevan–McGregor
<alice at gothcandy.com>wrote:

> On 2011-01-02 09:21:29 -0800, Guido van Rossum said:
>
>> Alice hasn't posted a link to her rewrite of PEP 444 in a while. AFAICT
>> it's this: https://github.com/GothAlice/wsgi2/blob/master/pep444.textile. I find it a bit disturbing that the "official" copy of PEP 444 (
>> http://www.python.org/dev/peps/pep-0444/ ) hasn't been updated. This is
>> confusing for occasional observers (like myself), since the python.orgcopy looks quite dead. It also is not in line with the PEP workflow as
>> written down in PEP 1 (
>> http://www.python.org/dev/peps/pep-0001/#pep-work-flow ).
>>
>
> I am unsure of the policy behind updating a PEP on the website from a
> partial (with glaring holes) source.  In my rewrite there are several
> sections that need to be fleshed out before I would consider pushing it
> up-stream.
>
> I'm tentative that way.  ;)
>

Please drop the perfectionism. It is unpythonic. :) We believe in "release
early, release often" here.

Even if *you* believe there are no glaring holes, others will find them
anyway. The point of having incomplete drafts up on the website (and in SVN)
is that everybody has the same chance of seeing the draft. (Also note that
the website version is the first hit if you type "PEP 444" into a search
engine.) If it's incomplete in places, just put XXX markers in it. People
are used to this. Publication to the website does not imply any kind of
approval -- it just is a mechanism for people to comment on a draft in a
uniform way. (Also, a detailed SVN history might help people see the
relevant changes -- a big bulk update doesn't shed much light on what
changed since it looks like *everything* changed.)


> PEP 3333 is an excellent solution that should be quick to adopt.  My PEP
> 444 rewrite takes a fundamentally different approach in an attempt to
> simplify and solve broader problems than pure compatibility.


It might be good if you summarized the differences, either here (on the
list) or in the PEP itself. Unlike the documents issued by some standards
bodies, Python PEPs are meant to be readable documents, and can contain
sections about motivation, history, examples, whatever else the author deems
likely to sway its acceptance. The formal specification itself can be in a
section labeled as such.  (PS: I saw you just posted a quick summary, for
which I am grateful. Maybe you can add a more thorough one to the PEP
itself.)

 First, it would be great if Alice could prepare a version of her draft in
>> the format required for PEPs, and submit it to the PEP editors.
>>
>
> I will make this a priority.


Great!

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20110102/8eb6ed89/attachment-0001.html>