[Web-SIG] WSGI in standard library

Ian Bicking ianb at colorstudy.com
Tue Feb 14 22:45:06 CET 2006


Robert Brewer wrote:
> Alan Kennedy wrote:
> 
>>3. If I had to pick one of the 3 you suggested, I'd pick the 
>>last one, i.e. PJE's, because it fulfills exactly the criteria
>>I listed
>>
>>  - It's pretty much the simplest possible implementation, 
>>meaning it's easiest to understand.
> 
> 
> I have to disagree (having examined/unraveled it quite a bit recently,
> to remove modpython_gateway's dependency on it). The server class seems
> simple enough, but the handlers module is IMO horribly convoluted,
> mostly to support too many options: async vs. threaded, origin and
> non-origin servers, various HTTP versions, file sending hooks, etc.
> There are simply too many variables involved in building a WSGI handler
> appropriate for your environment; trying to do that by subclassing
> wsgiref.handlers.* results in extremely complicated and slow code.

I think it also tries to enforce a lot of the details of WSGI, and thus 
guide a WSGI implementor into creating a compliant server.  But in the 
process it creates a framework that has to be correctly used, so it's 
swapping a well-understood set of bugs (doing something you aren't 
supposed to with WSGI) for a different set (using the handler incorrectly).

paste.lint is reasonably good at checking WSGI compliance (those parts 
that are actually detectable) without caring about what your code 
actually looks like.  I think it is easier to use, with largely the same 
effect.

For the actual server a framework seems unnecessary, as there will only 
be two servers in the standard library (I assume) -- CGI and HTTP (and 
hopefully HTTPS will be easy to build off of HTTP).

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Web-SIG mailing list