Pimping the 'cgi' module (was: Re: python gaining popularity according to a study)

[Harry George]

Christoph Haas <email at christoph-haas.de> writes:

> On Thursday 23 November 2006 21:29, robert wrote:
> > When a LAMP programmer comes to Python, there are so many different
> > confusing things. It starts with a 'non-documented' cgi module - a
> > 'High-Level-Interface', that cannot even iterate over the form items. A
> > name ZOPE in focus which reveals to be a monster system with 2-year
> > learning-curve, ready for running an article editorial system for TOP-10
> > newspaper companies, but unable to make simple things simple. A handful
> > of different Djangos - choose one for each weekday and programmer ...
> > And Ruby made it with this single-known simple URL-to-method-router (And
> > possibly when coming from PHP & Perl one recognizes ::@$_$%§§%/&... and
> > the old namespace dirt) If there would have been a good cgi-system and a
> > somewhat comfortable advanced URL-to-OO-router (beyond the socket
> > wrapper HTTPServer) well exposed in the Python standard lib, the numbers
> > would be probably very different today ...
> 
> I can fully second that. Coming from Perl and being used to the CGI module 
> that is de-facto standard and already doing things much better than 
> Python's equivalent my first thought was: "Does Python really expect me to 
> re-invent the wheel to write basic CGIs?" So I started creating 
> cookie-based session handlers, form field handling etc.
> 
> The reason of my posting it not only to complain though. My Python skills 
> are average but I would really like to help contribute some code on this 
> topic. I don't know Ruby-on-Rails myself but I have worked with CGIs for 
> ten years both in C (yuk) and Perl (Perl=semi-yuk / Perl-CGI=yum) and 
> think I know what people coming from Perl expect. And I'm not speaking of 
> Zope or Django or huge frameworks. I try to avoid frameworks wherever I 
> can (I want to write Python - not Zope or Django). I rather rely on the 
> standard library unless it's really saving me time and worth learning 
> another language. Are frameworks perhaps even telling that the standard 
> library is still lacking in some way?
> 
> I'm thinking of features like:
> - cookie handling
> - cookie-session handling (similar to PHP or Perl's CGI::Session; combined
>   with database backends or simple text files)
> - handling of form fields (Perl's CGI class can easily redisplay what
>   has been entered in the fields when they got submitted through a <FORM>)
> - accessing parameters (honestly I haven't yet understood why I need to use
>   .value on FielStorage dictionaries - why isn't it just a plain
>   dictionary?)
> - state keeping (storing the contents of all form fields on disk
>   to retrieve it later)
> - creating form elements easily (option lists for example from
>   dictionaries and lists like in Perl)
> - creating standard HTML elements (or do you remember how DOCTYPE
>   looks without looking it up?)
> - handling of file uploads (which is just a recipe on ActivePython
>   at the moment)
> - controlling HTTP headers (expires, redirections, charset)
> - convenience functions e.g. for getting the client IP address without
>   needing to read ENV['REMOTE_ADDR']
> 
> Well, of course there are modules like 'cgi' or 'cookielib' and others may 
> argue that everything is already there. And there is a 'Web.py' already (I 
> assume every CGI programmer has written their own Web.py already). But 
> can't we come closer to what other scripting languages provide? Something 
> common? Can't a simple form-based CGI just be a matter of a dozen lines? 
> When it comes to CGIs Python loses its elegance for no reason.
> 
> I'm ready to invest work and ideas if anyone else is interested. Perhaps 
> some day it makes it into the standard library or at least gives us 
> something between the features of the standard library and huge framework 
> monsters - something people can be pointed at when starting with Python 
> and CGIs. I'll probably do that anyway because my web projects all use 
> their own reinvented wheel and I'm losing the overview. And even Perl has 
> come that route - it started with a cgi-lib.pl which later became 
> the 'CGI' standard module.
> 
> Is it just a matter of lacking resources or interest? Even if there is no 
> interest I'll probably read "man CGI" and "man CGI::Session" again and 
> start implementing something nifty for ex-perlies like myself. Hmmm, 
> batteries included even for CGI programmers, a man can dream. :)
> 
> Cheers
>  Christoph

When I came from Perl, I too missed perl-isms and specifically CGI.pm, so wrote my own:
http://www.seanet.com/~hgg9140/comp/index.html
http://www.seanet.com/~hgg9140/comp/pyperlish/doc/manual.html
http://www.seanet.com/~hgg9140/comp/cgipm/doc/index.html

Others on this newsgroup said I'd be better off just doing it in raw
python.  After a while, I realized that was true.  You do
triple-quoted templates with normal python idioms.  Throw in
some persistence mechanisms to deal with maintaining state across
transactions, and you are in business.

Since then I've looked at Zope, Plone, TurboGears, Django, and (for
standalone apps) Dabo.  TurboGears is mostly a set of recommendations
on what 3rd party packages to use, with a wee bit of glueware.  So far
nothing feels as simple as just doing it in python.

-- 
Harry George
PLM Engineering Architecture