[Web-SIG] Adding wsgiref to stdlib
ianb at colorstudy.com
Fri Apr 28 21:32:35 CEST 2006
Guido van Rossum wrote:
> 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'm asking Phillip to post the URL for the current
> source; searching for it produces multiple repositories.)
> I believe that it would be a good idea to add wsgiref to the stdlib,
> 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.
I'd like to include paste.lint with that as well (as wsgiref.lint or
whatever). Since the last discussion I enumerated in the docstring all
the checks it does. There's still some outstanding issues, mostly where
I'm not sure if it is too restrictive (marked with @@ in the source).
I think another useful addition would be some prefix-based dispatcher,
similar to paste.urlmap (but probably a bit simpler):
The motivation there is to give people the basic tools to simple
multi-application hosting, and in the process implicitly suggest how
other dispatching can be done. I think this is something that doesn't
occur to people naturally, and they see it as a flaw in the server (that
the server doesn't have a dispatching feature), and the result is either
frustration, griping, or bad kludges. By including a basic
implementation of WSGI-based dispatching the standard library can lead
people in the right direction for more sophisticated dispatching.
And prefix dispatching is also quite useful on its own, it's not just
> 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).
No one disagreed with the basic premise though, just some questions
about the particulars of the server. I think there were at least a
couple small suggestions for the wsgiref server; in particular maybe a
slight refactoring to make it easier to use with https.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG