![[WWW]](/wiki/classic/img/moin-www.png){kind=small}
hope that the Python community will support a coherent web platform better than CGI. The WSGI standard is a step in that direction, but only a small infrastructure step. If mean, this gigantic page: http://www.python.org/moin/?WebProgramming is the authoritative source for finding which platform to use. It's a bit ridiculous.
Right now, there's lots of hype about Ruby On Rails (http://www.rubyonrails.org/) which puts together features similar to the ones mentioned in the Frameworks section -- templating, object publishing, object-relational mapping.
Also, I'm a bit more cynical about how useful these high level automated features are for Deme, which makes use of complex database and web interactions seem to require lower level direct SQL and HTTP/HTML use.
newer updates (aug 2004): the quixote framework makes things look very doable. python in general suffers from a terrible over-abundance of many different frameworks, and too-small communities for each. cherrypy, for example, may or may not be better than quixote. there's no way to know until you try all of them.
a decent overview of server side environments: http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/dyncont.html
The biggest problem of python is a lack of total establishment. PHP does a LOT of nitty gritty html/http things for you....
[draft draft draft]
In the long term, we may want to consider a python rewrite. Follows is, basically, my case for a python rewrite.
Here are considerations I've thought of.
1. Language features
PHP is harder to write and use than Python. PHP has terrible consistency and error-checking; it won't even check incredibly basic stuff like whether an attribute on an object exists at runtime (so if you misspell a name, you get a NULL value, but keep on going...) Python has a well-designed and robust runtime type-checking system, with very good error handling (it has a full-out exceptiosn system).
Python libraries are much easier to use; you can import modules and the like. The PHP 'library' is just a huge collection of functions loaded when apache loads mod_php. In PHP it's impossible to even make user-defined libraries without writing them in C; instead of python's terrific modules and dynamic OOP, you have 'include' statements and bolted-on "classes" that arbitrarily lack useful features.
Python encourages good style and readability. Surface-level aesthetics are good: No $-signs, whitespace-based indentation. Furthermore, the entire library is designed to be logical and clean; language featuers and the api to manipulate basic python objects like lists and hashtables are incredibly intuitive. PHP doesn't have the same feel; though its string interpolation syntax is a bit more readable than python's, and especialyl useful for nitty-gritty web programming (like the code in marea/.)
2. Web UI vs. Internal Logic separation
The biggest consequence of PHP's weak structure is a lack of separation between the web UI and internal logic of POD, such as database interactions and decision logic and modularization. This is OK when working on the fine-details of the marea/ UI, but as we scale to include new featuers, things will only be getting messier since there's not a very good interface to the internal 'modules' in lib/.
Much of the problem stems from all the work that must be done to sync up php objects and mysql tables; the style of manipulating logical objects like docs, msgs, etc. is neither consistently OO nor SQL-relational; both are used. Part of this is my fault, but part of the problem is php's weak modules/oo; they're so hard to use, it's often easier to jsut exectue a bunch of mysql queries. New poll,msg,folioitem creation follows this pattern of using sql insetad of a clunky chunk of oo-creation code. (sqlobject, see below, would solve this problem very well)
A python-based system would be much more structured than the current php system; it would be far far easier to extend and divide into separate vomponents for multiple developers to work on. Decision logic modules could be written and tested from the commandline (FAR easier than through a web ui), and non-web interfaces could be supported in the future, too. (chat systems, desktop GUI's, etc....) or supported in a much more robust manner than what'll happen with php.
3. Python frameworks
The largest obstacle to using Python (one of the main considerations in the original decision to use PHP) is the lack of a developer-consensus framework to develop web apps in Python. If you use the PHP language, that means you're developing apps with mod_php and the php library. Thousands and thousands of php users program it in this way; there's ample documentation and such online.
If you use Python, there are numerous ways to do it, at varying levels of abstraction... cgi, fastcgi, mod_python, webware, zope... Just to research all these alternatives is a task in and of itself. Unfortunately, aside from Zope (which is crazy complex) there's no good overarching framework to handle everything; instead you must find the good components and use them together, yourself.
I think (as of 12/27/2003) I've found a good python framework, based on the following components:
-
Webware (specifically, the webkit component) for the appserver and servlet architecture. This resembles the java servlet system.
-
ALTERNATIVE:
Mod_Python is a smaller, easier-to-install alternative that's not *totally* obscure in the wider web world. It requires a tad bit more of piecing together your own libraries; but it's not too bad.
-
SQLObject for a great relational-db object mapper. If PHP had something like this, the current codebase's size could be cut by a huge amount, perhaps 30%!
-
Cheetah templating system may also be useful, it seems to be the closest thing to a consensus-chosen templating system that the python web programming community has. PyMeld is also very interesting but may have performance concerns.
-
apache, mysql (like now)
4. Developer Communities
The user and developer communities for these frameworks are smaller than php's; on the other hand, the python community has a very high ratio of smart people willing to give a lot of help. If you post a question on comp.lang.python you'll receive serveral responses in just a few hours, for example. many of the posts are quite high-level and insightful, in my (subjective) experience.
I haven't been able to find a comparable resource for php developement. But simple google searches show the difference: google to try to answer some question about php, and you'll get dozens of random posts from newbies in random forums with no response. google to get an answer to a python question, and often you'll get mailing list archives that answer the question much more fully, with pointers to other resources, etc.
[In all fairness, I may simply have failed to find a comparable PHP resource; some must exist, surely]
I also think that folks in the python community could be supportive of POD itself. The python community is self-consciously open-source (not always so for php world) and python developers seem to keep up with a wide variety of open-source developments and software. Again, most of these judgements I've made from reading comp.lang.python.
5. Hosting situations
Another obstacle to Python viability is hosting. PHP is virtually universally deployed for unix/linux hosting environments; python is rarer. If we are intending POD to be installable on any old web hosting server, PHP is a better language for that.
most python web systems out there, to the extent they exist, run on Zope. Non-zope systems usually confine themselves to CGI, which is deployed everywhere, but is quite inefficient. webware (or mod_python) solves these efficiency problems. However, to install this requires admin-level access to the server; in a shared hosting environment, you don't have access to that; instead, you must ask the admins to install it for you, or else look for hosting that does python. There's a list of such services at http://www.python.org/cgi-bin/moinmoin/PythonHosting but there are many, *many* more that do PHP.
If you run your own server, and have experience in linux/unix installation and setup of software, then it's not too difficult to setup webware to work with apache, or even easier, just install mod_python.
These concerns are irrelevant for piece.stanford.edu or whatever the home site of POD is, since we'd have full control over that.
6. External software, developer culture
This section is more tenuous and subjective than the others.
There are LOTS of 3rd-party software packages out there for php that can be used. There's a smaller quantity of stuff for python. however, it often seems the case to me that the python libraries are higher quality; certainly, they're far easier to integrate and install, simply because python has a modules system.
Furthermore, the authors of python modules tend to be very self-conscious of themselves as developers; they provide documentation and helpful email feedback. Often php stuff is found on websites with names like "freescripts.com" and comes from a culture of "how can i hack together scripts to make my website run?" rather than "how can i make a resuable, well-wriiten component?" Maybe this judgement is unfair; there certainly there are many well-written (as well-written as possible, that is) php components out there. phpMyAdmin comes to mind... but there's just so much php junk out there, it's hard to find the well-written gems in the sea of "freescripts".
Sometimes there's a developer intent for the php software, but the code itself is deceptive and requires lots of hand-hacking to integrate it correctly. the PEAR User Authentication system is a great example; I foolishly seized on to it as an example of a useful PHP module and stuck it in POD; unfortunately, it's proven very difficult to use correctly, and annoying to fix. Much of this problem stems from the inherent hard-to-read and hard-to-structure properties of PHP.
Python design philosophy is also helpful: often there's a "pythonic" way of doing something, and developers can design their software according to that philosophy. sqlobject's use of new-style classes to transparently map objects to sql rows, is a terrific example. This philosophy, again, is self-conscious among python developers.
Also: if only loose integration is needed, we could potentially use php components within the python system. This integration would be messy, but if the coupling is very loose then it's fine. For example: php code to read and edit a calendar. The only coupling needed is to be integrated with the pod user system. As an immediate example, phpMyAdmin could still be used for our own piece developers udner a python/mysql system.
xMSx xMSx
