[Web-SIG] Naif wanting to improve CGI handling

[Matthew Scott]

On 2006 Nov 24, at 08:43, Christoph Haas wrote:

> Frankly I'm unhappy with the 'cgi' module in the standard library. A
> posting on the python-user mailing list made me rethink why web
> programming is so painful for me in Python while it was easy in Perl
> (while everything else was hard in Perl which is easy in Python). IMHO
> Python deserves at least a good CGI implementation. And since I'm  
> used to
> Perl's 'CGI' module I would at least expect the same functionality in
> Python.

Keep in mind that packages in the Python standard library tend to  
have a slower development pace than packages that are available  
elsewhere, e.g. the packages listed at cheeseshop.python.org

Because of this tendency, there are packages in the stdlib that have  
not changed in terms of interface or implementation for quite a  
while, with the exception of bugfixes or to add support for new  
syntax (like the new 'with' keyword in Python 2.5)

I have a feeling that even if the "cgi3k" package comes with the  
Python 3.0 standard library, there will still be a "cgi" package kept  
around to support the large amount of code out there that relies on  
that package.


> While reading what is already done and learning about this SIG I  
> found the
> PEP333 that really scared me. I'm personally not interested in Python
> acting as a web server. I'm used to run Apache and use CGIs that  
> deal with
> stdin, stdout and environment variables. So my expectations are pretty
> close to Perl's 'CGI' and 'CGI::Session' modules. But it sounds  
> like it's
> pretty mandatory to use WSGI if I want to add any layer of  
> functionality.

Don't get too scared by PEP333 :)  Phillip J. Eby, PEP 333's author,  
seems unabashedly detailed and verbose in his writing style, but I  
think that's a very good thing for a specification that is being read  
and implemented by a large audience.

If you want a gentler introduction to WSGI, try reading some of the  
stuff at http://wsgi.org/ -- especially in the "Learn WSGI" section.

The interesting thing about WSGI is that you don't have to use Python  
as a web server to use it.  Once you wrap your head around what WSGI  
gives you and what it doesn't, it is not too much different from  
using stdin/stdout pipes and environment variables at a low level.

Many people do end up using Python as a web server in some regard  
when using WSGI though, since doing so can provide increased  
performance and makes the handling of persistent objects (such as  
sessions, database connections, etc.) easier.

It is possible to write a WSGI application that can run either as a  
CGI script, or as a long-running process, connected to Apache via  
proxying or FastCGI for example.

As far as the list of features that you desire from CGI, there are a  
growing number of WSGI applications that act as filters.  See for  
example http://pythonpaste.org/ -- there are more resources on the  
wsgi.org site, and also on cheeseshop if you search for WSGI.

Basically, you write your application as a WSGI application, then use  
third-party WSGI applications to "wrap" your application inside  
session handlers, form handling helpers, and so forth.


> Should I just go ahead and create yet another framework and  
> increase the
> chaos by joining the dark side? Or is there work going on where my  
> ideas
> would fit in and where my revolutionary energy saves the world? I  
> would
> love to see my Python skills - as average as they may be - create
> something useful not only for me. I hope someone of you has enough
> overview over the current activities to provide a little guidance.  
> Thanks
> in advance.

The concept of programmers, seasoned or not, contributing to a larger  
pool of useful software and ideas is one area where WSGI is making  
some traction.  Ian Bicking puts it well in this entry of his: http:// 
blog.ianbicking.org/wsgi-update.html

"""
WSGI development can seem kind of plodding at times, because we're  
building up slowly from a low-level foundation. But as the tools  
emerge they work together really well; I think we're starting to see  
real returns from that process. ...
"""

For instance, you may find that something like httpy -- see http:// 
www.zetadev.com/software/httpy/ -- gives you an interface that is  
easier to grok than "bare-bones" WSGI.  By using such software  
though, you will find that it still fits right in with other WSGI  
applications that offer useful services like session management, even  
if those apps are written using different techniques.

And again, if written in such a way as to provide for it, a WSGI app  
can be served up as a CGI script :-)


--
Matthew Scott
mscott at springfieldtech.com