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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
