[Web-SIG] WSGI in standard library
ianb at colorstudy.com
Sun Feb 5 02:12:55 CET 2006
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):
> 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
More information about the Web-SIG