Summary
Hopefully this isn't as controversial as adding setuptools. :-) Comments to python-dev and/or web-sig at python dot org, please.
Advertisement
PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
it's written by Phillip Eby who put a lot of effort in it to make it
acceptable to very diverse web frameworks. The PEP has been well
received by web framework makers and users.
As a supplement to the PEP, Phillip has written a reference
implementation, wsgiref. I don't know how many people have used
wsgiref; I'm using it myself for an intranet webserver and am very
happy with it.
I believe that it would be a good idea to add wsgiref
to the Python standard library,
after some minor cleanups such as removing the extra blank lines that
Phillip puts in his code. Having standard library support will remove
the last reason web framework developers might have to resist adopting
WSGI, and the resulting standardization will help web framework users.
Last time this was brought up there were feature requests and
discussion on how "industrial strength" the webserver in wsgiref ought
to be but nothing like the flamefest that setuptools caused (no
comments please).
I'm inviting people to discuss the addition of wsgiref to the standard
library. I'd like the discussion to be finished before Python 2.5a3 goes out;
technically it can go in up till the 2.5b1 code freeze, but I don't
really want to push it that close. I'd like the focus of the
discussion to be "what are the risks of adding wsgiref to the stdlib";
not "what could we think of that's even better". Achieving a perfect
decision is not the goal; having general consensus that adding it
is better than not adding is would be good. Pointing out
specific bugs in wsgiref and suggesting how they ought to be fixed is
also welcome.
PS. To get wsgiref via anonymous SVN: svn://svn.eby-sarna.com/svnroot/wsgiref
The name, the name... My first reaction was "Is Guido posting about web services?". There are a lot of weblog posts contra SOAP-based web services with things like "Putting the ws-cart in front of the ws-horse"; the web services standards itself have names like "ws-secure", "ws-authentication", "ws-transport".
"swgiref" reminded me immediately of a misspelled "ws-grief".
So I'm hoping it 'll end up in the standard lib as just "swgi" :-)
I understand what you would like to do but I don't understand your motivations (despite you are using wsgiref and it works well for you). Could you please elaborate on this ?
After looking at wsgiref (couldn't access the link you give, server is not responding. Does it use wsgiref...), I think a more complete solution is needed, something that at least provides a unified and extensible way to deal with sessions, get, post and cookie variables. So -1 from me at the moment. Flup[1] looks like a better candidate.
> I think a more complete solution is needed, something that > at least provides a unified and extensible way to deal > with sessions, get, post and cookie variables.
I think you're confusing including wsgiref with the stdlib blessing a web framework. Guido has already said he's just not going to do the latter. The idea of having wsgiref is to have a *reference* implementation of useful tools for working with the WSGI protocol. Some of these tools are framework-like in the sense that it's intended for people to subclass them. However, they do not constitute a web framework in the sense of defining interlocking classes and conventions; they are simply subclassable standalone tools.
> Flup[1] looks like a better candidate.
I'm open to expanding wsgiref, as per current discussion on the Web-SIG about including a simple demo resolver or two. Sophisticated production-class resolvers like those in Paste, Routes, and Flup are out of scope, though, because the point is to emphasize simple, correct, and (ideally) extensible code.
Looking at Flup, I would say that if the author wants to contribute the "gzip" and "error" middleware components, clean them up to follow stdlib naming conventions, and make a couple of tweaks to improve extensibility (mainly allowing subclasses to use something besides smtplib.SMTP to send mail), I'd be happy to have them in wsgiref.
+1 this would be very nice. I just started using web.py with wsgi and it would have made the installation process quicker.. (for me as a newbie that makes a difference..)
A standalone WSGI Server implementation shouldn't be longer than 300 LOC imho. Paste has got a small WSGI Server, there is this WSGIUtils (hope the name is correct) server and afaik some others like my test wsgi server implementation: http://trac.pocoo.org/repos/sandbox/BaseWSGIServer.py
And maybe the CGI gateway from the pep too.
And maybe a "wsgi" package providing some comfort functions like a CgitbMiddleware and methods for parsing form data like in the cgi package. I known that you can use the cgi functions with wsgi too, but you have to grep the informations out of the wsgi environ yourself. Some small helper functions would be nice.
IMHO just two small Modules `BaseWSGIServer` (according to other servers) for the WSGIServer and a `wsgi` package for utility functions would be better :)
Previous Topic
