[Web-SIG] PEP 444 != WSGI 2.0

[Alice Bevan–McGregor]

Graham,

> GothAlice (don't know off hand there real name), keeps going around and 
> claiming:

Alice Zoë Bevan-McGregor.  If the unicode in my newsreader doesn't 
work, that's an e with an umlaut.

> I have pointed out a couple of times to them that there is no way that 
> PEP 444 has been blessed as being the official WSGI 2.0 but they are 
> not listening and are still repeating this claim. They can't also get 
> right that PEP 3333 clearly says it is still WSGI 1.0 and not WSGI 1.1.

Interestingly, we're both wrong.  PEP 3333 clearly states it's WSGI 
1.0.1 -- it's in the title.  My excuse is 60 hours straight of sleep 
depravation over the holidays.  ;)

> Because for all we know right now what will be WSGI 2.0 may look a lot 
> different to what PEP 444 is now.

That's not a technical reason against, that's a reason to step in and 
help shape the future.

> Already they have taken the original PEP 444 that was put out by Chris, 
> and which had never actually been updated based on feedback on the 
> Python WEB-SIG list to address perceived shortcomings, and started 
> injecting his own ideas on top of it without any real consultation with 
> those on the WEB-SIG who have had a lot of experience with all this 
> stuff.

I, too, have a fair amount of experience with WSGI, having utilized a 
nubmer of alternate frameworks, worked around several common issues, 
ripped apart the top 10 HTTP servers to examine their inner workings, 
torn apart a framework or two, written a performant HTTP/1.1 server 
against both the published PEP 444 draft and my rewrite, and have 
written my own framework used on a number of production deployments in 
at least four countries.

If you'll pardon the expression, it's not like I'm a random ass-hat off 
the street with two weeks of Python experience.

> Thus what he is working on is a very fluid specification that keeps 
> changing. Ie., it is thus a work in progress, yet the way they talk 
> about it is if it already is the official WSGI 2.0 specification when 
> it is still no more than a bunch of ideas of what could be done.

"He" and "they."  Better than "it", I suppose, though last time I 
checked I'm not "people". ;P

It's a draft PEP.  Looking at it, it prominently states at the top of 
both the published and rewritten versions: draft.  Pretty much any time 
I mention my rewrite of it (for clearer RFC-style language and 
disambiguation) I either explicitly call it a "draft" or use language 
indicative of a work in progress.

> [snip] Don't do this and all you do is cause ongoing confusion in the 
> community as to what WSGI 2.0 is given that the definition of what it 
> may be keeps changing.

>From a comment I made on your blog:

> PEP 3333 is a simple-to-implement organic evolution of PEP 333, and 
> thus requires (or should require) little work on the part of the WSGI 
> application developer or WSGI server author. PEP 444 is a clean break.

And further elaborated in further comments:

> PEP 3333 can do a lot of good while maintaining gross compatibility 
> between Py2K and 3K with the same WSGI1 API across both. Also as stated 
> before, PEP 3333 should be ratified As Soon As Possible™. The support 
> is there from the developers implementing it, the implementation is a 
> refinement of PEP 333 w/ clarifications, and all can be happy.
> 
> PEP 444 / WSGI 2 is completely different in goals and approach.

I think it's fairly clear that 3333 is closer to ratification and 
simpler to migrate to, and is a clear way forward for the short- to 
mid-term.

> I also have a various technical issues with the original WSGI 
> specification and they aren't being addressed in PEP 444 from what I 
> have seen so far, as well as having issues with new things in PEP 444.

Have you read my draft rewrite? [1] It incorporates solutions to a 
number of the problems you have described in various articles on your 
blog.  In fact, it's modeled fairly heavily after your "definition 4" 
and its use of native strings.

> I have blogged and posted on the WEB-SIG list about a number of them 
> and am now starting to get back into documenting what some of those 
> other issues are.

I look forward to further input.

> Overall though, I believe a big step needs to be taken back and fresh 
> look at this stuff needs to be made.

That was the goal of the rewrite.  PEP 444 / web3 as published on the 
Python website does fail to solve a number of problems.

> It needs to be cast into the greater context of how we deploy this 
> stuff as well, otherwise deployment is going to continue to be a PITA 
> with all the systems using different ways when there could be a better 
> level of compatibility across them all to make deployment easier.

Deployment isn't really the domain of the web interface API; we have 
distribute, pypi, eggs, etc., etc. for literal package distribution 
(including deployment).  I think a separate PEP should be used to 
describe, say, entry point-based high-level deployment similar to 
PasteDeploy, as an example.

	- Alice

[1] http://bit.ly/e7rtI6