I would like to converge my development categories (programming, admin scripting, web dev) into a single language, and Python is enjoyable enough that it could be the top candidate. So far, the biggest hurdle has been finding where web development and Python converge. It appears that the Python community has not settled on any particular standard, framework, or methodology.
Personally, I was leaning toward a search for the most simple and elegant solution. I initially didn't want to invest the effort into learning about a mammoth web application server like Zope, and I wasn't interested in all the extras included with Webware. So, I searched through the numerous projects and solutions available, and eventually decided Spyce was worth playing with. Compared with other Python web framework projects, it seems to be one of the most current and well developed, but it's goals are very simple. It's essentially Python server pages for those familiar with PHP and ASP. It's probably also worth mentioning that I started contemplating a mix of the simple framework of Spyce and the methodology behind FuseBox 2.0.
Recap Goals: modularity of code across sites, fusebox type framework, simplicity in the python to web implementation, templating language optional - not required, easy learning curve
Links:
http://spyce.sourceforge.net
http://www.fusebox.org
http://www.boddie.org.uk/python/web_frameworks.html
http://www.python.org/cgi-bin/moinmoin/WebProgramming
The install:
I use rpm's when possible because they are fast, simple, and clean. This makes them perfect for just testing a package. If you're a compiler, sorry.
[root@drain root]# uname -a;cat /etc/issue Linux drain.dotpipe.org 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown Red Hat Linux release 7.2 (Enigma) Kernel \r on an \m [root@drain root]# cd /usr/local/src/ [root@drain src]# wget http://unc.dl.sourceforge.net/sourceforge/spyce/spyce-1.3.6-1.noarch.rpm --18:44:01-- http://unc.dl.sourceforge.net/sourceforge/spyce/spyce-1.3.6-1.noarch.rpm => `spyce-1.3.6-1.noarch.rpm' Resolving unc.dl.sourceforge.net... done. Connecting to unc.dl.sourceforge.net[152.2.210.121]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 420,146 [application/x-redhat-package-manager] 100%[========-snip-==========>] 420,146 200.34K/s ETA 00:00 18:44:04 (200.34 KB/s) - `spyce-1.3.6-1.noarch.rpm' saved [420146/420146] [root@drain src]# rpm -ivh spyce-1.3.6-1.noarch.rpm Preparing... ########################################### [100%] 1:spyce ########################################### [100%] Adding Spyce config to httpd.conf... done. /usr/sbin/apachectl graceful: httpd gracefully restarted [root@drain src]#
This investigation stalled not too long after the installation. That may be dissapointing, but it probably says something as well. The Spyce technology does a pretty decent job of allowing someone to use Python in a similar fashion to Active Server Pages or PHP, but it has some problems too. There are several ways to configure Spyce to run including via cgi/fcgi, via mod_python, and via proxy to a built in server. The fast cgi method was used for most of my testing.
I did some light coding and setup some of the examples from documentation. The main problem I noticed was with the performance and lack of caching I thought should be occuring. I wasn't too motivated to pursue a solution to this problem but I'm sure it could be overcome with proper Apache setup, file permissions, and pre-compiling of the python scripts. Overall, the Spyce experience was a little clunky and too imbedded into the html code. Spyce is more geared toward embedding parsable code in the html and I'm more interested in seperating presentation and logic. Also, I was very bothered by the loss of white space delimiting when your Python chunks get seperated. I understand the difficulty of keeping that integrity, but it's also something that is key to my enjoyment of Python which led me to Spyce in the first place.
All of this was enough for me to abandon the project for the time being. I'm already investigating Zope though, and I could imagine a time when the simplicity of Spyce might call me back. I look forward to checking up on Spyce's progression in the future.
Copyright 2003 dotpipe.org