[Web-SIG] WSGI in standard library (was: A trivial template API counter-proposal)

[Guido van Rossum]

On 2/4/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Phillip J. Eby wrote:
> >> Perhaps wsgiref
> >>should go into the Python 2.5 standard library?)
> >
> > Sure.  I'd suggest that we might want to expand it a little to include some
> > of the fine contributions of other authors, such as Ian's "lint" middleware
> > (which sits between an app and a server and checks both for compliance) and
> > maybe even his "Python debugger in the browser" middleware.  There have
> > also been people who've written a few utilities for CGI-in-WSGI, WSGI in
> > mod_python, etc.  And it'd be nice to squeeze in a FastCGI implementation
> > if somebody's got a suitable one.  Docs are also nonexistent at the
> > moment.  I'd be happy to co-ordinate and consolidate the additions, and of
> > course I'll write documentation, though any assistance people can offer
> > would be greatly appreciated.  Some people have written nice WSGI tutorials
> > or explanations, so if anybody wants to offer those up for consolidation
> > into docs, that would be good too.
>
> There's some pieces that I think are not yet ready for standardization.
>   For instance, the error catching middleware would deserve a much
> larger discussion, I think, as it also involves the question of how to
> extend tracebacks (it uses Zope's code that uses magic local variables).
>   Also, the interactive implementation is complex enough (including
> Javascript) that I can't envision it stabablizing sufficiently.  (Paste
> includes a cgitb-based catching middleware as well)
>
> 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.

> The CGI server in wsgiref is also very stable -- there's not much for it
> to do.  Flup includes FastCGI, SCGI, and AJK, both forking and threaded.
>   I think all these pieces have relatively few dependencies, which could
> be extracted.  No forking WSGI HTTP server exists that I know of.
>
> paste.lint is pretty stable and complete, I think.
>
> With a little adaptation, paste.urlparser.StaticURLParser and
> paste.urlparser.PkgResourceParser also could be useful -- these are
> static file serving apps (they should be renamed, of course).  Serving
> with pkg_resources doesn't make sense unless pkg_resources is in the
> standard library.  But both those are based on paste.fileapp.FileApp --
> which serves a single file -- and while Clark has also done some work on
> that and it is improved, I feel less confident that it is complete (but
> it could be completed -- its scope is well-understood).  Finding a file
> is easy (that's what StaticURLParser does), but actually serving a file
> with full HTTP support is a little more complex.  Also support for
> encoding and expiration times is missing from those -- mostly a matter
> of passing related configuration.  I think a good static file serving
> implementation is really valuable.
>
> paste.cgiapp is relatively simple (runs a CGI script).  I think
> paste.proxy (just added) would be a really nice contribution to the
> standard library -- an HTTP proxy to another server, appearing as a WSGI
> application -- but the implementation is rough and only a couple of days
> old.
>
> There's also a bunch of the routines in paste.request, paste.response,
> and paste.wsgilib could be good for the standard library.  There's also
> some code in paste.httpheaders, which perhaps could be made simpler and
> more primitive-feeling -- for things like parsing header values
> according to their meaning in HTTP.
>
> There's several other bits of Paste that are pretty straight-forward,
> but not necessarily important.  E.g., a middleware that profiles the
> internal request and includes that in the output.  And some parts that I
> think are really useful, but abstract in a way that might not make
> everyone comfortable -- like paste.urlmap for mounting applications, or
> paste.cascade for trying multiple apps in a row until one "succedes"
> (where success usually means doesn't-return-404).

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).

> 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?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)