[Web-SIG] WSGI in standard library

[Ian Bicking]

Guido van Rossum wrote:
>>I think a WSGI-based HTTP server is fairly easy to stabalize.  Clark
>>Evans contributed a server based on SimpleHTTPServer, which I think is
>>both pretty complete and doesn't do anything besides HTTP serving (e.g.,
>>no static file serving):
>>http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py
> 
> 
> I'm confused. I downloaded wsgiref and it seemed to be implementing an
> HTTP server based on BaseHTTPServer.

Yes, I had forgotten about that.  I myself haven't used wsgiref that 
much.  It would be useful to analyse the differences between these two 
implementations.  Paste's HTTP server has some more HTTP 1.1 features, 
but that might actually be problematic for the standard library.

> Can I recommend that you be *extremely* conservative in suggesting
> stuff to go into the stdlib? Once it's in there, you have no way of
> upgrading it until the next major release (i.e. 2.6) which is
> typically an 18-24 months timeframe -- minor releases (e.g. 2.5.1)
> aren't allowed to add new features, only to fix bugs. EGGs and other
> 3rds party install methids (by design, actually) can't easily be used
> to upgrade standard library modules/packages. ISTM that wsgiref itself
> is stable enough, and having it in the stdlib would lower the bar for
> anybody to develop WSGI-compliant apps even if they refuse to use a
> toolkit. A lot of the other things you're mentioning above seem to be
> of a different kind -- nice-to-haves, for sure, but either they're not
> 100% stable yet, or they enter the slippery slope of appearing to be a
> specific framework choice (cgitb already has that feel to me).

Yes, I'm not really seriously proposing anything now, just brainstorming 
things.  Phillip brought up the interactive debugger, and thought there 
were *lots* of things far more appropriate than that; that doesn't 
necessarily mean those parts are really appropriate.

Also, I suppose there's no reason that the standard library has to be 
the landing place for "standard" code.  Stuff in the standard library 
needs to have a PEP, but a PEP can describe something that never intends 
  to go in the standard library.


>>If stuff was put into the standard library, I think it would be
>>important to consider up-front how the code would be backported.  I'm
>>not really happy with the ad hoc backporting of libraries that currently
>>occurs.  And I don't want to maintain the same code in Paste and a
>>standard library module, or use cascading imports in my code.
> 
> 
> I'm not sure what you mean by "backporting". Can you clarify?

Well, for instance optik and logging are provided for installation on 
older versions of Python.  And PyXML.  But these aren't consistently 
backported, enhancements are often not backported, and what backports 
that exist aren't listed anywhere.  And users have to do various kinds 
of cascading imports if they want compatibility.

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