[Web-SIG] Naif wanting to improve CGI handling

[Paul Boddie]

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

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

Good luck!

Paul