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

[Paul Boddie]

Christoph Haas wrote:
> 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.

Zope was simultaneously one of the best things to happen in Python Web
programming, but also one of the worst, mostly because people saw the
power of the solution, correctly realised that it could do a lot of
things they would otherwise have to do themselves, but then got locked
into an approach which wasn't suitable for every kind of application.
It was like having a handful of fairly promising parties ruined by the
opening night of an expensive nightclub where the first two drinks were
free.

> > A handful of different Djangos - choose one for each weekday and programmer ...

The handful of Djangos isn't necessarily a problem, but there is this
"all or nothing" mentality in writing and promoting Web frameworks. Or
rather, an "all or lots of little pieces" mentality. One is left either
with a room full of tiny Lego bricks to put together, or one actually
has to be the python and swallow a large solution whole, hoping that it
all tastes good - even the nasty parts.

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

There was probably a window of opportunity to include the old Bobo
dispatcher (or perhaps the "Poor Man's Zope" stuff) in the standard
library, but rigid dispatchers of that style arguably aren't sufficient
any more, even though they can be regarded almost as the original
"URL-to-OO router". If you look now, there are a number of
dispatchers/routers that work in a more-or-less independent way from
frameworks, however.

> 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 standard library expects you to do that, yes, since many of the
Web-related modules were written in the infancy of the Web and have
only been conservatively updated since. I remember when the cookie
handling went in, and it was a big but overdue event back then.

> 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 believe so, and I'm not alone with that opinion.

> I'm thinking of features like:

[List of HTTP-related, persistence-related and templating-related
things]

> I'm ready to invest work and ideas if anyone else is interested.

Take a look at this page for some other work with similar goals:

http://wiki.python.org/moin/WebStandardisation

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

Some people will argue that you just want a big framework (implying
that they know what you want better than you do), whilst others will
talk about lots of reusable middleware. I don't disagree with the
component-based solution mindset, but the bricks really have to be
bigger, and there needs to be a picture on the box showing what the
finished model looks like, along with some clear instructions on
getting started.

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

I am aware of at least one person who seems dissatisfied with the
current level of standardisation and who wants something a bit more
obvious for those who don't want to take the "30 second Wiki" route.
Perhaps they could openly publish their ideas or proposals and we could
establish some kind of unofficial standard around those things. I'd
certainly be interested in moving things forward in that regard.

Paul