CGI with Python: advantages?

[Alex Martelli]

"Moshe Zadka" <moshez at math.huji.ac.il> wrote in message
news:Pine.GSO.4.10.10008061322100.14285-100000 at sundial...
> On Sun, 6 Aug 2000, Mimmo wrote:
>
> > The question is: is Python a good language for CGI scripting?
>
> Yes! But that's not the question <wink>, the question is CGI scripting
> good? I'm sure Cameron will chime in with the usual "CGI is not obsolete
> yet", but you might want to explore other solutions, both within and
> without Python: Zope, Enhydra, Java Servletes, Perl's HTML::Mason,
> PHP, mod_snake or even more exotic stuff like custom HTTP servers in
> Python (CGIHTTPServer.py) or Tcl.

Besides exotic stuff, you might also be well advised to explore
_minimal_ tweaks on the CGI concept that will let you run stuff
that's very close to CGI scripting, but in a far more efficient
way.  FastCGI is probably the main incarnation of that idea, and
it's widely available; see http://www.fastcgi.com/ -- you can
run that under Apache and Microsoft's IIS, as well as Netscape
and Zeus servers if those are what you have.  Python is among
the best-supported languages for FastCGI, IMHO; Robin Dunn's fgci.py
for serialized stuff, and Andreas Jung's sz_fcgi.py if you like
multi-threading, make FastCGI from Python a piece of cake.

For those of us who like Xitami (for its utter simplicity, light
footprint, &c), Robin Dunn has also developed LRWP, the "Long
Running Web Processes" protocol, very similar to FastCGI but much
simpler.  Again, as one would expect from hearing of Robin as its
architect, Python support is excellent.  Incidentally, both
fcgi.py and lrwplib.py (and I would assume sz_fcgi.py and the
various C equivalents too, though I haven't checked) let you
develop scripts that can perfectly well run under any good old
plain CGI too, with no changes and no problem; and 'porting' from
fcgi.py to lrwplib.py is a snap too.

(AFAIK, unfortunately, only Xitami supports LRWP, although its
simplicity suggests that porting to Apache should be feasible
if one wanted to give it a try).

All the other stuff Moshe mentions IS well worth looking at, but
the CGI programming model is pleasingly simple, and FastCGI and
LRWP give it a longer lease of life, IMHO.  Develop with one of
them (depending on your target server), debug under CGI, deploy
with the chosen server...


> > Does it offer something more (speed, efficency or whatever else) than
> > Perl or other languages used to write this kind of scripts?
>
> If you're looking for speed and efficiency, I think the main overhead in
> most CGI scripts is the prohibitive start-up time. While Python's start-up
> time is longer then Python, they are pretty close -- if you're starting

I'm not sure if Moshe means that Perl's start-up is longer than Python
(since the latter leaves the compiled .pyc files around for next time)
or vice-versa (as was reported recently for certain Unix configurations).

> I've programmed some CGIs in Python, and it is very easy. However, do note
> that Python's cgi.py is closer to Perl's CGI::Lite  then to Perl's CGI.pm.
> If you want cool HTML generation, you should get the htmlgen module. If
> you find this is really a need, consider if you're not mixing code with
> graphic design and or content, and if CGI is the correct solution for you.

Generating HTML in clever ways is such a snap from Python that there are
umpteen ways to do it.  htmlgen is perhaps the most-widespread, but often
I prefer the (admittedly ASP-like) approach of having a little bit of
code mixed in with an HTML template; there are lots of solution for that
too, but it was fun to develop my own (YAPTU, Yet Another Python Template
Utility).  The regular expressions that delimit Python expression and
statements in YAPTU are fully configurable, but a typical look of a
YAPTU template is:

<strong><font size=5><br>
Carte note:</font></strong>
    <font size="4">
                <u>Ovest</u>:
    <select name="kw" size="1">
+for i in range(0,14):
+  if i==kw:
        <option selected>@i@</option>
=  else:
        <option>@i@</option>
-
-

with the @i@ delimiting an expression, and the + (start of a Python
nesting level), = (continuation thereof) and - (end thereof) at line
start, being my typical choices when the template is meant to
generate HTML.  But, as I said, you get another thousand choices
if you don't like this kind of approach...!


Alex