No need to go sowing seed like this!
No need to go sowing seed like this!
I'm a big fan of Django, but you'd have to admit that Django's "one virtual host for Python, another for static files" would over-complicate installation. Even on a made-for-Django host like WebFaction it would still be easier to install PHP-WordPress than Django-WordPress.
Setting that up? You just have to install a python egg in the app directory and you should be good to go.
Like I said, it's implementation details - a python application could be made easy-to-install. It's just that no one has built a special purpose application with a single minded install path (Django can be self-hosted, mod_python, or mod_wsgi but it is a framework and not an application in the sense that WordPress is an application and CakePHP is a framework) that is relevant to WordPress, closest probably being Plone.
When wide acceptance is the goal, even small frictions can be material.
This matters, facts or no.
However. I still think a well engineered application that could cater to many of the $5 hosts' python setups could be just as easy to setup as a PHP app.
Sure you could have RPMs or Debian packages tailormade for a specific distribution, but WordPress has the advantage that it's a downloadable package that can easily be (S)FTP'd into a folder on a shared host and run, and it'll work with most hosts. You just can't do that with Django-WordPress.
Again, I use Django/Python more than PHP these days, so it's not a PHP versus Python thing.
As an example, here is the index.wsgi front-controller that loads my Pylons app (note, mine is more complicated than I'm showing here because I use virtualenv to contain the app):
from paste.deploy import loadapp
application = loadapp('config:/home/my_app/production/production.ini')
The host makes sure that the Apache vhost has mod_wsgi configured to run a WSGIDaemon process for the /home/my_app/production directory - typically (in the case of WebFaction) they give you an interface that handles all of that (so you can run multiple apps out of the same top level directory) in the course of creating your "sites", the same exact process you would go through for creating "sites" for a PHP based application.Also, you don't need to tailor RPM's to the distribution, you can package your app as a python egg (which is cross-platform and contains the dependency links in your setup.py). I almost think this is easier than (S)FTP'ing the app up to your host. If your host gives you SSH access (which all $5 a month hosts do as far as I know - the crappier ones put you through a verification process, but a good one will give it to you the minute you are signed up) you can easily rsync the app up and then run "python setup.py whatevercommandyourappuses" and bam - you're good to go.
You could even put the database creation steps into the setup.py routine - "python setup.py build", "python setup.py install" <---- build necessary directories, then build your database tables for you. Much safer (and easier) than supplying an install script that can be accessed publicly.
I will concede though, that the whole scenario I've just described wouldn't be easy and fast for the average joe due to their inexperience with Python and/or the command line... That kind of thing makes me wonder though why we don't have basic programming courses as a requirement in high-school. If only my father (a lawyer) knew what sed/grep/awk could do for his manipulation of documents... I'm digressing now and I'll stop.
I know it isn't a PHP vs. Python thing - it just frustrates me when people make the argument for an inferior tool in favor of ease of use when ultimately (as per the scenario I gave above) the more powerful tool can save you time... I came from PHP land and will not go back - thanks in part to Python and the other methodologies I've learned.