[Web-SIG] Naif wanting to improve CGI handling
paul at boddie.org.uk
Sun Nov 26 00:34:12 CET 2006
Christoph Haas wrote:
> I have just subscribed to this list and while I waded through a few
> postings in the list's archive I might not have a clear picture of what's
> currently really going on. So I may ask about things that you have decided
> on already.
I've just resubscribed after a while, mainly because I think your proposal is
interesting and provides a dimension that was originally considered in the
establishment of this mailing list, but which has been lost over time.
> 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
While your focus is on the cgi module, and it may be the case that you're
specifically interested in CGI as an execution model (with standard input,
output, environment variables, and so on), I interpret your sentiments more
broadly as a desire for a simple API which works with CGI and other
technologies, and where the style of programming is as transparent as
old-fashioned CGI scripts: you can clearly see how the program gets its
inputs, makes its decisions, and then produces its output.
Am I right in thinking this? If so, then you've found at least one other
person who thinks there should be a fairly reasonable and obvious foundation
for Web programming in the standard library, where "obvious" means an API
which deals with high-level concepts familiar to Web programmers in other
communities, and where "reasonable" means that you don't have to run some
highly specific server solution to use it.
Of course, there are arguments against advancing the standard library in this
way, mostly expressing the sentiment that if you want things to be easy, you
should be using a megaframework. But whilst some people have advocated the
use of Django (for example), and whilst frameworks like Django provide a
fairly reasonable API at some level, there are good reasons for not launching
newcomers towards megaframeworks at the first opportunity. First of all, it
makes Python itself difficult to advocate: "Use Python for Web programming?
Batteries not included? You mean I have to choose from this list?" Secondly,
the megaframeworks often have a confusing message: the Django tutorial goes
off into creating database models at the very start, for example - something
thankfully rectified in the draft Django book - and this doesn't appeal to
people wanting to start simple and get "hello world" or "hello form data" up
and running. Thirdly, it means that lots of different groups are doing things
their own way when they don't have to; whilst WSGI reduces this, the
phenomenon persists at the API level.
And I think the API level is critical because that's what programmers relate
to. As long as they can have some flexibility in the way they deploy their
code, and as long as they don't have to spend a day just configuring servers
before they can get started, that aspect isn't interesting at the earliest
stage of exploration. Instead, people want to know what the code has to look
like, whether they can stomach writing it that way, and whether there's
anything out there to make it more pleasant to work with when doing common
things like outputting forms. That web.py came along even after the most
prominent megaframeworks made their entrance says a lot about the demand for
simplicity and transparency in some quarters.
> 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?
Probably against all other advice you're going to get, I'd recommend that you
look at WebStack, Indra and httpy (all on the WebStandardisation page) and
spend less time looking at the frameworks on the WebFrameworks page. What
you'll get from WebStack is a sense of what it's like to make something like
the Java Servlet API but applicable for anything from CGI to Zope; from Indra
you'll see a fair amount of consideration given to the common interfaces
needed in a Web framework (with the list of interfaces corresponding somewhat
to your long list of desirable features); from httpy you'll see a wrapping
around WSGI to make it more obvious to developers outside the WSGI community.
Where your revolutionary energy saves the world is where you get to propose
something that enters the standard library as a better API everyone can use
to further whatever applications or megaframeworks they choose to develop and
More information about the Web-SIG