Python web development, really

[Jonathan P.]

>From http://lists.free.net.ph/pipermail/python/2003-January/000381.html :

Ok, I've checked the majority of them out and 
Spyce gets my thumbs up.  I looked especially
closely at CherryPy and Quixote because the
2 looked the most promising initially.  

CherryPy 0.8
============
In spite of my enthusiastic first impression, I 
found CherryPy a bit too verbose and was not 
convinced that views/functions/masks were 
essential abstractions.  CherryPy also makes use
of templates which I later realized was something
I didn't want to deal with as much as possible.
CherryPy's unique feature is that your site
compiles down to a python script which is its
own server!  Pretty neat.  Now if they could
incorporate Medusa's ideas for boosting scalability
into the generated server...

Quixote 0.5.x
=============
I thought Quixote's code-centric style would be 
to my liking.  However, it had just enough complicated 
details that I decided to try my luck somewhere else.  
If there were not so many other choices, I'd probably 
have stuck it out with Quixote.  I didn't think it
was really all that hard to figure out and I had the 
gut feel there was a LOT of power under the hood, but 
I wanted something I could work with with as little 
new studying as possible.

Webware and Skunkweb
====================
I then decided to check out these two mainstays again.  
On doing so, I realized a key fact.  No matter how 
nice templates are, like I found PHP's Smarty
Templates to be, I realized in the end that they just 
get in the way of an experienced programmer who will 
always be able to do much better with straight code.

Skunkweb did not look like it had a good way of embedding
real Python code in HTML - relying pretty heavily on STML -
or at least that's the impression I got from its docs.  With
Webware, I remember being less than fully satisfied with PSP 
circa 0.4.x - the somewhat hard to read <% %> tags were one 
reason - so I had an excuse to check out the other 
alternatives.

Skunkweb's 'hype' makes it sound like it's the most reliably 
scalable of all the solutions... although I suspect that the
principles it uses will not be hard to apply to the others
with a little work.  

Spyce
=====
I was initially turned off by Spyce's "Hello World" example.
Those [[ and ]]s are not good for readability.  However, I 
found out that it had a [[\ operator which basically was an
escape to pure Python code and was exactly what I was looking 
for.

Spyce gives me the vanilla PHP-like functionality I want(*) -
the kind of straight Python-code embedding that PyHP, PyML, 
PMZ, Fenster provide except that these projects seem to have 
been abandoned.  Plus, upon closer inspection, Spyce seems 
to be quite mature and has evolved quite a few really nifty 
features.

(*) The only other 'living' alternative seems to be Webware's 
PSP... pls. correct me if I'm wrong...

I was somewhat turned off by the fact that the docs asked
me to install fastcgi before running it but the fact is that
Spyce will work with plain cgi.  Later on, I was sufficiently 
enamoured with Spyce that I even installed modpython and now 
that I plan to use it, may even upgrade to Apache 2.x so I 
can use modpython with my thread-enabled Python interpreter 
without worries.

Cheetah
=======
Another great bonus of Spyce is that it can work with Cheetah,
the one templating system which I felt like I could live with.
Instead of using hard-to-read < and >s, it uses $-prefixed 
variables.  Cheetah is its own templating project independent of 
any Python server-side project and seems to have grown quite
sophisticated.  It is intended to be a plug-in to Python
server-side solutions or stand-alone as a template processor
(say for static HTML generation).

I believe Cheetah is nice enough that it will prove useful one 
day even for someone like me who eschews templates for real 
code.

Performance and Reliability
===========================
My theory was that using a Python server-side solution meant 
I could just use kinterbasdb to access Firebird databases
the way I've been doing in my Linux client apps along.  This
is actually the reason I explored a Python server-side solution 
- I didn't want to experiment anymore with interfacing between 
PHP and Firebird.  After I got Spyce running, I quickly and
joyously confirmed that theory.

Now that I have a 3-tier setup, I can realistically examine
performance and reliability issues.

I made a simple spyce script to fetch a big result from a
Firebird DB.  It was a total cinch by the way, see code
below.  Python's DB-API kicks the excellent, now _formerly_
excellent, PHP ADODB's butt any day of the week/month/year.  
Let's not even talk about the native PHP MySQL or Interbase 
APIs.

==== kinterbasdb.spy =====
[[\
import kinterbasdb
con=kinterbasdb.connect(dsn="localhost:/path/to/data.gdb",
                        user="foo",password="bar")
cur=con.cursor()
cur.execute("select * from big_table")
results=cur.fetchall() ]]

<html><body><pre>[[ for r in results: print x ]]</pre></body></html>
===== end of kinterbasdb.spy ======

With Firebird on the same server as Apache and using
mod_python, performance felt decent (no hard figures
yet) at the very least.  mod_python looks like the way 
to go (even better than fastcgi) and could be a good 
excuse to upgrade to Apache 2.0.

Questions and more insights on issues - I'm especially
interested in python interpreter spawning differences
between mod_python and fastcgi, as well as Apache 1.3.x 
vs Apache 2.x pros and cons - very happily entertained.