[Web-SIG] PEP 444 != WSGI 2.0

[Graham Dumpleton]

On 2 January 2011 16:28, Guido van Rossum <guido at python.org> wrote:
> On Sat, Jan 1, 2011 at 5:02 PM, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
>> Can we please clear up a matter.
>>
>> GothAlice (don't know off hand there real name), keeps going around
>> and claiming:
>>
>> """
>> After some discussion on the Web-SIG mailing list, PEP 444 is now
>> "officially" WSGI 2, and PEP 3333 is WSGI 1.1
>> """
> [...]
>
> From past posts here, that's Alice Bevan–McGregor
> <alice at gothcandy.com>, added to the thread.
>
> On Sat, Jan 1, 2011 at 8:34 PM, Ian Bicking <ianb at colorstudy.com> wrote:
>> Until the PEP is approved, it's just a suggestion.  So for it to "really" be
>> WSGI 2 it will have to go through at least some approval process; which is
>> kind of ad hoc, but not so ad hoc as just to implicitly happen.  For WSGI 2
>> to happen, someone has to write something up and propose it.  Alice has
>> agreed to do that, working from PEP 444 which several other people have
>> participated in.  Calling it "WSGI 2" instead of "Web 3" was brought up on
>> this list, and the general consensus seemed to be that it made sense -- some
>> people felt a little funny about it, but ultimately it seemed to be
>> something everyone was okay with (with some people like myself feeling
>> strongly it should be "WSGI 2").
>>
>> I'm not sure why you are so stressed out about this?  If you think it's
>> really an issue, perhaps 2 could be replaced with "2alpha" until such time
>> as it is approved?
>
> I'm guessing that Graham is concerned that Alice's assertion implies
> that the PEP is approved.

I certainly don't take it as being approved because I know that PEP
444 is quite incomplete at this time. It is the perceptions others get
when they are being told that PEP 444 is WSGI 2.0 that I am worried
about.

> IOW that the *future* WSGI 2.0 is equal to
> the *current* PEP 444. While we don't know for sure, this is likely
> wrong (at least in some details).
>
> OTOH I agree with Ian that it seems correct to say that PEP 444 (which
> is still under development) is striving to arrive at a consensus for
> what will be named WSGI 2.0. This is not unusual in the world of
> standards -- future standards usually are given names and document IDs
> long before there is agreement on the contents of the standard. In
> this sense Alice's use of "officially" is not incorrect, although out
> of context it could be misunderstood to imply PEP approval. I would
> recommend adding caution about this whenever the equivalency between
> PEP 444 and WSGI 2.0 is mentioned -- perhaps it is enough to state
> that "PEP 444 is the draft for WSGI 2.0".

I'd suggest that that is even too strong. You are giving the
impression that no one else can separately come up with another
proposal, especially one that is significantly different.

> Often people or companies draw premature conclusions from draft
> standards and prepare implementations that comply with the draft
> standard in the hope that the draft won't change before it is set in
> stone, and sometimes such implementations are incorrectly billed as
> compliant with the standard (rather than with a specific version of
> the draft). I don't know if that is what Alice is doing -- an equally
> likely theory is that she's just excited.
>
> I haven't followed the development of PEP 4444 much, so I can't
> comment on how much agreement there is on the draft; Ian's use of
> "alpha" suggests that there's some way to go still.
>
> One clearly factual error in Alice's (quoted) post: PEP 3333 is WSGI
> 1.0.1, not WSGI 1.1. AFAIK there's no such thing as WSGI 1.1 now.
>
> Alice, since you have in the past posted here suggesting you are
> interested in carrying PEP 444 / WSGI 2.0 forward, please acknowledge
> that you understand the concerns raised in this thread.
>
> Graham, I suggest that you don't worry about this issue, and instead
> focus on helping the draft turn into a standard by providing feedback
> on PEP 444.

That may be too late. Alice and I haven't exactly hit it off well.
Using the #webcore IRC channel as the forum to work on it as Alice
wants is also totally inadequate. IRC is just not a suitable forum for
discussing this. It is just not possible to fit into a few lines what
takes pages to explain to a level that people can understand. As much
as this mailing list has caused seemingly never ending discussions in
the past that go no where, it is still the appropriate forum for any
discussion.

> Unless there's part of the story you're not telling here.

It should be no secret that I have been progressively poking holes in
the existing WSGI specification through my blog posts and suggesting
remedies. Overall I still see what is being done as more of a band aid
solution. The whole thing needs a rethink because even when you patch
some things, the design in some areas is arguably broken, eg.
wsgi.file_wrapper. Just dropping features or ignoring the fact they
are broken isn't the answer though.

There may also be merit in seeing whether the minimum Python version
be increased such that a solution could may use of new language
features added since Python 2.3. In Python 2.3 you couldn't yield in a
try block. You also didn't have the with statement. No one is looking
at how WSGI might be made better by utilising such new features or at
least understanding properly how the existing specification interacts
with them.

Take for example PEP 325 which the close() method for resource
reclamation was based on. That PEP was rejected in the end and was
replaced with PEP 342 which worked quite differently, yet I cant see
that the WSGI specification was revisited in light of how it ended up
being implemented and the implications of that.

As I have said before, I also still believe that any revised
specification needs to take into consideration deployment. Right now
deployment is still a bit of a mess. If standardisation around a
strategy for how you deploy is reached then likely would be a separate
PEP, but you don't want a situation where it still a bit of a fudge
because the base WSGI specification doesn't make it easy and an
opportunity was missed to change it.

So, what am I saying that isn't being heard, only that I don't want to
see a band aid solution. I had hoped to devote a lot more time to all
this in the coming year now that I have changed jobs and have more
flexibility, but am concerned that it is being taken down a specific
path with no ability to change it.

Graham