Need a compelling argument to use Django instead of Rails

V

Vincent Delporte

Typically you run PHP as a module in your webserver, so there should be
no process startup overhead. mod_python provides the same sort of
functionality for Python, but is not as popular or widely installed as
the PHP Apache module.

So, if mod_python provides the same functionality, it's not the main
reason why Python developers use application servers while PHP users
still program with page codes in /htdocs.

Why do PHP users stick to that old way of things? Because they mostly
use shared hosts, with no way to install their application server?
 
T

Terry Reedy

Ben Sizer said:
As for PyGame, it's
good that development there has picked up again but I'd love to see it
broaden its horizons beyond SDL. Maybe that is impractical, however.

By wrapping SDL and interfacing to Numeric, Pete Shinners picked a chunk
that he could chew and maintain. The Pygame site has recently added a
PyGame Cookbook or the equivalent so people can more easily share small
chunks built on pygame and comment thereupon.

tjr
 
B

Bruno Desthuilliers

Vincent said:
So, if mod_python provides the same functionality, it's not the main
reason why Python developers use application servers while PHP users
still program with page codes in /htdocs.

Why do PHP users stick to that old way of things? Because they mostly
use shared hosts, with no way to install their application server?

PHP has never been designed to allow writing such a thing as a web
server (some may say that PHP has never been designed at all, but this
is another troll^Mquestion). IIRC, it was initially meant to run as cgi,
then rewrote as an apache module.

And the fact is that while there's no startup overhead in PHP (at least
when deployed as a module), you still have to rebuild the whole world
(includes, app-specific conf etc) for each request. This is what
long-running application servers try to solve.

mod_python is at once lower-level and a bit more powerful than PHP. It
really exposes most of Apache's API to Python - which BTW doesn't make
it that well-suited for shared hosting... (most of the time, updating a
mod_python based app requires restarting the server).
 
G

Gerhard Fiedler

I'm not sure about PHP users in general, but I think that there are many
sites hosted on shared hosts. Many of those sites need a solution for
dynamic pages. That's quite a market.
mod_python is at once lower-level and a bit more powerful than PHP. It
really exposes most of Apache's API to Python - which BTW doesn't make
it that well-suited for shared hosting... (most of the time, updating a
mod_python based app requires restarting the server).

Why is that (restarting required)? And is there a way to "lock down" a
mod_python installation WRT Apache, in a way similar to a typical PHP
installation? AFAIK there are a number of shared hosts that support Python.
I'm not sure whether that's mod_python, though...

Thanks,
Gerhard
 
B

Ben Sizer

Vincent said:
So, if mod_python provides the same functionality, it's not the main
reason why Python developers use application servers while PHP users
still program with page codes in /htdocs.

Why do PHP users stick to that old way of things? Because they mostly
use shared hosts, with no way to install their application server?

Yes, one reason is because they can't install anything other than web
pages. Not only can they not install a Python application server, they
can't install mod_python either, and few places will have it
pre-installed. Shared hosting accounts for a massive number of sites so
this is a significant issue.

Another perfectly good reason is that PHP pages are much simpler to
deploy than any given Python application server. Just add the code into
your HTML pages as required and you're done. Python could come close to
this if something like the Python Server Pages implementation in
mod_python was to become widely available and well known, but that
still requires overcoming the first problem.
 
P

Paul Rubin

Ben Sizer said:
Another perfectly good reason is that PHP pages are much simpler to
deploy than any given Python application server. Just add the code into
your HTML pages as required and you're done. Python could come close to
this if something like the Python Server Pages implementation in
mod_python was to become widely available and well known, but that
still requires overcoming the first problem.

I didn't realize you could do shared hosting with mod_python, because
of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user. A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).
 
B

Ben Sizer

Paul said:
I didn't realize you could do shared hosting with mod_python, because
of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user. A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).

Ah yes, I hadn't considered that. Is this a Python limitation?
Py_Initialize() seems to initialise a global Python object which
obviously makes it awkward to share. Other languages allow you to
create multiple instances (eg. Lua has lua_newstate() which returns a
new Lua state) which would facilitate running multiple interpreters
without the new process overhead. A brief search implies that mod_perl
doesn't have the same problem as mod_python (but has other problems).
It would be a shame if Python is almost alone in having this issue.
 
A

Alex Martelli

Ray said:
Well actually I was thinking of exaclty the same thing, because our
apps are mostly CRUD apps anyway. However I just learned of one very
big killer--lack of support for Oracle and MS SQL Server. That pretty
much shoots Django down from the list, and with it Python.

According to
<http://wiki.rubyonrails.com/rails/pages/Framework+Performance>, with
Rails...:

"""
When connecting rails to Oracle the performance dropped to the extent it
made any production use of the product useless.
...
Oracle. I would bet performance degrades dramatically when Rails
connects to Oracle as Rails does not use Bind Variables or cache
prepared statements. Not using bind variables in Oracle is the single
most common mistake. When running the load test connected to Oracle,
does Oracle consume a lot of the CPU?
Its unfortunate, as until Rails handles Oracle correctly, its not really
fit to be used on it, and I was really hoping to use it there!
"""

IOW, if these comments are correct, Rails is also _practically_ unusable
with Oracle. Meanwhile, Django has experimental Oracle support with a
patch (<http://code.djangoproject.com/ticket/1990>, latest checkin is
from Jul 31, but it has been around for over a year in some form or
other). As to what will mature first, Rails/Oracle performance or the
Django/Oracle patch, who knows. I suspect it won't matter much, because
"buzz" trumps substance (in the short run, at least), and Ruby on Rails
has buzz (according to Tim O'Reilly's reports at OSCON last week, sales
of Ruby books have overtaken sales of Perl books recently -- Python
books, while gaining relative to Perl, are still below).

The one big issue that may preserve Perl, Python and PHP against Ruby's
onslaught is -- acronyms. Any of the "P" languages can acronymically be
part of a "LAMP" setup, one of the coolest acronyms in years; indeed,
BSD, PostgreSQL and lighttpd may already have been handicapped by the
un-coolness of acronyms such as BLPP. But Ruby suffers even worse here,
since somebody using Ruby instead of a P-language would be a... LAMR!!!

If I were on the board of the Ruby equivalent of the PSF, I'd be
lobbying hard for the language's name to be changed to PRuby -- with the
P being mute, as in Wodehouse's character Psmith. _That_ would remove
the acronymical barrier and ensure PRuby's triumph.


Alex
 
A

aaronwmail-usenet

Paul said:
I didn't realize you could do shared hosting with mod_python, because
of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user. A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).

You just need to run multiple apache
instances, which is advisable anyway.
The hosting service formerly known as
python-hosting has been doing this
for years. For example my http://www.xfeedme.com
site uses it (which seems to be down at the moment!
oh no! :( ).
-- Aaron Watters

ps: little known fact: mod_python descends
from an NSAPI plugin implementation
I wrote as an example of embedding python in
the defunct "Internet Programming
with Python" book. Books die, but software lives on.

===
if you are happy and you know it stick with your dosage.
-- seen in the New Yorker
 
B

Ben Sizer

You just need to run multiple apache
instances, which is advisable anyway.
The hosting service formerly known as
python-hosting has been doing this
for years.

Would you need one instance per user? Is it practical to run 1000s of
Apache instances on one server?
 
A

aaronwmail-usenet

Ben said:
Would you need one instance per user? Is it practical to run 1000s of
Apache instances on one server?

I'm almost certain Apache spawns instances as needed.
If they are all active at the same time you will need at least
that many threads anyway and I don't think processes
are really much more expensive than threads usually.
But I'm not an expert on virtual hosting or apache or
even thread/process internals.

However when I do a "ps -aef" on my shared server
(http://www.xfeedme.com) I only see the apache
instances that are active, and not the 50 dormant
ones, if I recall.

-- Aaron Watters

===
She was flirty, dirty, musta been about thirty
-- 70's stones lyrics
She was nifty, shifty musta been about fifty
-- 90's stones lyrics
 
B

Bruno Desthuilliers

D

Damjan

I didn't realize you could do shared hosting with mod_python, because

Yes, but your mod_python programs still run with the privileges of the
Apache process, as are all the other mod_python programs. This means that
my mod_python program can (at least) read files belonging to you -
including your config file holding your database password.

PHP solves this problem by using it's safe mode and basedir restrictions.
Mod_python nor Python itself don't have this feature.

There are sollutions for Apache that run each virtual host under a different
uid but they have quirks:

Metux MPM - http://www.metux.de/mpm/en/
mod_suid - for apache 1.3.x
http://www.palsenberg.com/index.php/plain/projects/apache_1_xx_mod_suid
mod_suid2 - for apache 2.0.x
http://bluecoara.net/item24/cat5.html
mod_ruid - seems to be an improvement of mod_suid2
http://websupport.sk/~stanojr/projects/mod_ruid/

But I see mod_python more as a way to extend Apache itself, than for running
Python applications. A lot of the Apache mod_auth_* modules could be
replaced with mod_python scripts.

OTOH SCGI or FastCGI seem better sutied for python web (WSGI) applications.
 
A

aaronwmail-usenet

Damjan said:
Yes, but your mod_python programs still run with the privileges of the
Apache process, as are all the other mod_python programs. This means that
my mod_python program can (at least) read files belonging to you -
including your config file holding your database password....

I think a standard solution to this is to
associate each virtual host server to a
different port and have the main apache
redirect to the port. Inetd makes sure
that the vserver apache instance only
stays alive while it's needed. It might be
complicated to set up, but it works.
Again, something like this is probably
advisable anyway to limit the ways one
vserver can damage another generally
speaking.
-- Aaron Watters

===
It's not the years. It's the mileage.
-- Indiana Jones
 
D

Damjan

Yes, but your mod_python programs still run with the privileges of the
I think a standard solution to this is to
associate each virtual host server to a
different port and have the main apache
redirect to the port. Inetd makes sure
that the vserver apache instance only
stays alive while it's needed. It might be
complicated to set up, but it works.
Again, something like this is probably
advisable anyway to limit the ways one
vserver can damage another generally
speaking.

Starting a new Apache process with python included (trough mod_python) is
even worse than CGI.

But it seems AppArmor supports secureing mod_python (and mod_php and
mod_perl) with a special Apache module (and the AppArmor support in the
Linux kernel - yes this is Linux only).

http://developer.novell.com/wiki/in...ompare_with_regard_to_webserver_protection.3F

Now that it's GPL AppArmor seems to get a lot of supporters.
 
A

aaronwmail-usenet

Damjan wrote:>
Starting a new Apache process with python included (trough mod_python) is
even worse than CGI.

Yes, but I think only for the first interaction
after being dormant for a period. In fact I've
noticed that hitting http://www.xfeedme.com
the first time is usually slow. But once the
apache is up it seems to stay up until it has
been inactive for a good while, and it's fast.
I'm inferring all this from what I see using
"ps" and other indirect tools.

-- Aaron Watters

===
as the poet said:
"Everybody have fun tonight
Everybody Wang Chung tonight"
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top