Write web apps in Python?

G

Gilles Ganault

Hello

I'd like to make sure I understand what the options are to write web
applications in Python:

- à la PHP, using Apache's mod_python

- using eg. Lighttpd and configuring it to load the Python interpreter
every time a Python script is called (www.jakehilton.com/?q=node/54)

- long-running process, by compiling the Python script as a
stand-alone program that will then wait for queries on a port and
being called by the web server through eg. the WSGI

As for writing apps, I can either built it from scratch, or use
frameworks like Pylons, TurboGears, or Django.

Is this correct?

Thank you.
 
D

Daniel Fetchinson

I'd like to make sure I understand what the options are to write web
applications in Python:

- à la PHP, using Apache's mod_python

- using eg. Lighttpd and configuring it to load the Python interpreter
every time a Python script is called (www.jakehilton.com/?q=node/54)

- long-running process, by compiling the Python script as a
stand-alone program that will then wait for queries on a port and
being called by the web server through eg. the WSGI

As for writing apps, I can either built it from scratch, or use
frameworks like Pylons, TurboGears, or Django.

Is this correct?

Basically, yes.

For additional info have a look at http://wiki.python.org/moin/WebProgramming

Cheers,
Daniel
 
L

Luis M. González

Hello

I'd like to make sure I understand what the options are to write web
applications in Python:

- à la PHP, using Apache's mod_python

- using eg. Lighttpd and configuring it to load the Python interpreter
every time a Python script is called (www.jakehilton.com/?q=node/54)

- long-running process, by compiling the Python script as a
stand-alone program that will then wait for queries on a port and
being called by the web server through eg. the WSGI

As for writing apps, I can either built it from scratch, or use
frameworks like Pylons, TurboGears, or Django.

Is this correct?

Thank you.

You should first investigate the different python web frameworks,
choose one and then use the deployment options supported by your
choice. These frameworks support several ways to deploy your apps,
such as those you mentioned.

If you want an easy way to get started for free, check the Google App
Engine.
It's the google infraestructure to host web apps (written in python or
Java), and it's free as long as you don't surpass the limited quotas
on bandwith and data used (which are quite generous). You don't need
to set up anything. All you need is a google account to get started.

Luis
 
S

Stefan Behnel

Gilles Ganault, 12.04.2010 11:57:
I'd like to make sure I understand what the options are to write web
applications in Python:

- à la PHP, using Apache's mod_python

- using eg. Lighttpd and configuring it to load the Python interpreter
every time a Python script is called (www.jakehilton.com/?q=node/54)

- long-running process, by compiling the Python script as a
stand-alone program that will then wait for queries on a port and
being called by the web server through eg. the WSGI

Those are "deployment" options, not "write" (== design/implementation)
options. If you stick to a WSGI compatible framework, you are free to
deploy your application any way you like or need, depending on the specific
context or environment.

As for writing apps, I can either built it from scratch, or use
frameworks like Pylons, TurboGears, or Django.

Amongst tons of other options, as already pointed out.

Stefan
 
G

Gilles Ganault

You should first investigate the different python web frameworks,
choose one and then use the deployment options supported by your
choice. These frameworks support several ways to deploy your apps,
such as those you mentioned.

Thanks for the feedback. I wanted to have the big picture of the
different ways to write web applications in Python before checking the
different solutions.

So it looks like, unlike PHP, the prefered solution in Python is to
build a complete application as a long-running process, and either use
its embedded web server or configure a stand-alone web server to act
as reverse proxy using either FastCGI or WSGI to connect the two.
 
B

Bruno Desthuilliers

Gilles Ganault a écrit :
So it looks like, unlike PHP, the prefered solution in Python is to
build a complete application as a long-running process, and either use
its embedded web server or configure a stand-alone web server to act
as reverse proxy using either FastCGI or WSGI to connect the two.

Yeps. You'll find the same pattern with most general purpose programming
languages, and specially OO ones.

The PHP execution model (mostly based on CGI FWIW) tends to be a bit
unpractical for non-trivial applications since you have to rebuild the
whole world for each and any incoming request, while with a long-running
process, you load all your libs, parse your config etc only once.

Also, gateways like FastCGI or WSGI avoids being tied to a specific web
server.
 
G

Gilles Ganault

The PHP execution model (mostly based on CGI FWIW) tends to be a bit
unpractical for non-trivial applications since you have to rebuild the
whole world for each and any incoming request, while with a long-running
process, you load all your libs, parse your config etc only once.

Apart from the ease of having the application run at all times, I'd be
curious to read about an application that was written in PHP and then
a long-running process and see if performance improved.

Regardless, Python has an easier syntax, so AFAIC, that's already a
good enough reason to use this to write web apps.
 
B

Bruno Desthuilliers

Gilles Ganault a écrit :
Apart from the ease of having the application run at all times, I'd be
curious to read about an application that was written in PHP and then
a long-running process and see if performance improved.

I'm not sure there's a way to do such a thing in PHP, at least in a way
that wouldn't make the whole benchmark totally meaningless. And trying
to compare a PHP app with a similar non-PHP would also be (mostly)
meaningless.

Now there are a couple Symfony / Django benchmarks around (Symfony being
probably the closest thing to Django in the PHP world). They are just as
reliable as most benchmarks (that is, at best a rough indicator once you
understand what's effectively being measured), but it seems that they
confirm the empirical evidence that PHP is not well suited for such
"heavy" OO frameworks.
Regardless, Python has an easier syntax, so AFAIC, that's already a
good enough reason to use this to write web apps.

Indeed !-)
 
B

Bryan

Bruno said:
Gilles Ganault a écrit :

I'm not sure there's a way to do such a thing in PHP, at least in a way
that wouldn't make the whole benchmark totally meaningless.

I think you guys got some incorrect info about PHP. A variety of
execution options are available, such as FastCGI and in-server
modules. PHP frameworks generally allow and encourage application code
to be independent of the underlying plumbing. Many large,
sophisticated, high-volume web apps are in PHP.

We like Python 'round here, but PHP, Ruby, Perl, Java, and others are
viable languages for web apps. Each has its distinguishing features --
how efficiently a web app gets invoked is not among them. It's not a
language issue. What was the theory here? Did we think the PHP
community too stupid to understand FastCGI?
 
A

Adam Tauno Williams

Gilles Ganault a écrit :

There are numerous ways to efficiently retains state between page views
[session id + memcache or even just shared memory].
I'm not sure there's a way to do such a thing in PHP,

There isn't. [Speaking as an ~15 year administrator and developer].
Also PHP's memory management is *B*A*D*, so please don't try to create
long running processes in PHP.

But if you have intensive processing to do your web front end should
signal a backend to do the 'real' work; keeping your front end thin and
svelt. There are numerous ways to accomplish that.
 
B

Bruno Desthuilliers

Bryan a écrit :
I think you guys got some incorrect info about PHP. A variety of
execution options are available, such as FastCGI and in-server
modules.

mod_php, yes, but that doesn't change anything to the fact that it has
to rebuild the whole world on each and every request. Not the same as a
true long-running process.

So, yes, you COULD write a cli PHP app, daemonize it, and add a mod_php
/ FastCGI / whatever request handler to interface the cli app with the
web server, but that would be kinda pointless, wouldn't it ? FWIW,
that's what I was thinking about when asserting it would "make the whole
benchmark totally meaningless".
PHP frameworks generally allow and encourage application code
to be independent of the underlying plumbing.

This is debatable at best. PHP code (except cli PHP code of course) is
written without any care for persistent global state, concurrency
issues, race conditions etc - because it's written with the idea that
the code serving a request will be runned in total isolation. CGI
heritage here, obviously. And please note I'm not criticizing this
design- just pointing one of it's consequences.
Many large,
sophisticated, high-volume web apps are in PHP.

Did anyone pretend otherwise ?
We like Python 'round here, but PHP, Ruby, Perl, Java, and others are
viable languages for web apps.

Did anyone pretend otherwise ?
Each has its distinguishing features --
how efficiently a web app gets invoked is not among them. It's not a
language issue.

Well, when it comes to PHP, yes, it's somehow built in the language -
PHP was designed from the ground to be a server page language, and to
have each request served in total isolation (cf above).
What was the theory here? Did we think the PHP
community too stupid to understand FastCGI?

Bryan, I'm afraid you're reacting to something that was nowhere written
in this thread.
 
B

Bruno Desthuilliers

Adam Tauno Williams a écrit :
Gilles Ganault a écrit :

There are numerous ways to efficiently retains state between page views
[session id + memcache or even just shared memory].

Never played with shared memory in PHP. Sessions will at best retains
"state" (data), and it's not a free lunch neither (you'll still have to
reload that state one way or another). And you'll still have to parse
included .php files on each and every request.
I'm not sure there's a way to do such a thing in PHP,

There isn't. [Speaking as an ~15 year administrator and developer].
Also PHP's memory management is *B*A*D*, so please don't try to create
long running processes in PHP.

Wasn't designed for such a thing anyway !-)
But if you have intensive processing to do your web front end should
signal a backend to do the 'real' work; keeping your front end thin and
svelt. There are numerous ways to accomplish that.


For which definition of "intensive processing" ? Building a web page
with Drupal when you have a dozen modules hooked here and there can
already imply some processing...
 
A

Adam Tauno Williams

Adam Tauno Williams a écrit :
Gilles Ganault a écrit :
On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
The PHP execution model (mostly based on CGI FWIW) tends to be a bit
unpractical for non-trivial applications since you have to rebuild the
whole world for each and any incoming request, while with a long-running
process, you load all your libs, parse your config etc only once.
There are numerous ways to efficiently retains state between page views
[session id + memcache or even just shared memory].
Never played with shared memory in PHP. Sessions will at best retains
"state" (data), and it's not a free lunch neither (you'll still have to
reload that state one way or another).

I'd prefer the term "access" over "reload".
And you'll still have to parse included .php files on each and every request.

False. Production sites [all?] use interpreter caches that maintain
'compiled' pages in shared memory. This works *very* well.
Apart from the ease of having the application run at all times, I'd be
curious to read about an application that was written in PHP and then
a long-running process and see if performance improved.
I'm not sure there's a way to do such a thing in PHP,
There isn't. [Speaking as an ~15 year administrator and developer].
Also PHP's memory management is *B*A*D*, so please don't try to create
long running processes in PHP.
Wasn't designed for such a thing anyway !-)

Exactly; that never stops people from trying.
For which definition of "intensive processing" ? Building a web page
with Drupal when you have a dozen modules hooked here and there can
already imply some processing...

Again, the compilation of the modules is cached. The amount of
processing required for 'import...' declines to near zero.
 
B

Bryan

Bruno said:
Bryan a écrit :

mod_php, yes, but that doesn't change anything to the fact that it has
to rebuild the whole world on each and every request. Not the same as a
true long-running process.
So, yes, you COULD write a cli PHP app, daemonize it, and add a mod_php
/ FastCGI / whatever request handler to interface the cli app with the
web server, but that would be kinda pointless, wouldn't it ?

I think I see what you mean -- correct me if I'm wrong: You want to
keep complex application data structures around between requests. That
sounds appealing in terms of efficiency, but it's bad for scalability
and robustness.
This is debatable at best. PHP code (except cli PHP code of course) is
written without any care for persistent global state, concurrency
issues, race conditions etc - because it's written with the idea that
the code serving a request will be runned in total isolation. CGI
heritage here, obviously.

No, that's good web-app structure, regardless of language and server
interface. If we keep persistent global state in a shared database
rather than program variables, then we can run the app in multiple
processes and, if our service hits the big time, multiple hosts.

And please note I'm not criticizing this
design- just pointing one of it's consequences.


Did anyone pretend otherwise ?

How about this howler: "The PHP execution model (mostly based on CGI
FWIW) tends to be a bit unpractical for non-trivial applications".
 
B

Bruno Desthuilliers

Bryan a écrit :
I think I see what you mean
Err...

-- correct me if I'm wrong:

You are, sorry !-)
You want to
keep complex application data structures around between requests.

Nope. I want to keep all my settings parsed, my librairies loaded, all
my connections opened etc. That is, all the time consuming stuff at app
startup - which, with PHP, mostly happens for each and every request.
No, that's good web-app structure, regardless of language and server
interface. If we keep persistent global state in a shared database
rather than program variables,

Err... Did you really read what you're answering too ???

Also, I never said this execution model was necessarily bad - just that
it had pros *and* cons.
How about this howler: "The PHP execution model (mostly based on CGI
FWIW) tends to be a bit unpractical for non-trivial applications".

"tends to be a bit unpractical" != "doesn't work".

Many large, sopĥisticated etc applications are written in C. Does that
make C a practical application programming language ?

Now I'm sorry to say that for quite a few "sophisticated" PHP apps I've
seen (and eventually had to work on), the "startup" part - parsing the
include files, configuration, establishing connections etc - took a good
part of the total processing time.
 
A

Adam Tauno Williams

Bryan a écrit :

You are, sorry !-)


Nope. I want to keep all my settings parsed,

Store them in the session.
my librairies loaded,

Enable APC
all my connections opened etc.

If you are talking about RDBMS connections, use persistent connections.

Then you have everything you've asked for.
 
P

Paul Rubin

Bruno Desthuilliers said:
Nope. I want to keep all my settings parsed, my librairies loaded, all
my connections opened etc. That is, all the time consuming stuff at
app startup - which, with PHP, mostly happens for each and every
request.

I thought we have WSGI for this? Nothing stops a Python app from
working like PHP. PHP has an advantage when you want to run mutually
hostile apps in the same process (relevant if you're running ultra-cheap
shared hosting and you want to put 1000 customers' virtual hosts in the
same mod_php instance), but I don't think you're looking to do that.
 
C

Chris Rebert

Store them in the session.

I don't think that makes sense. You still have to re-parse the
settings upon starting each new session to store it in the session in
the first place.
Even then, you're suggesting needlessly keeping separate copies of the
settings data for each session, going from O(1) to O(N) in space;
that's rather wasteful.

Cheers,
Chris
 
B

Bryan

Bruno said:
Nope. I want to keep all my settings parsed, my librairies loaded, all
my connections opened etc. That is, all the time consuming stuff at app
startup - which, with PHP, mostly happens for each and every request.

O.K. I wasn't clear on your objection. As I said the first time, I
think you've gotten some bad info on PHP. Or maybe you're just behind
the times.
Many large, sopĥisticated etc applications are written in C. Does that
make C a practical application programming language ?

It's at least a strong clue.
Now I'm sorry to say that for quite a few "sophisticated" PHP apps I've
seen (and eventually had to work on), the "startup" part - parsing the
include files, configuration, establishing connections etc - took a good
part of the total processing time.

You didn't say when that was, but PHP caching has come a long way.
Google is your friend.
 

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

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,276
Latest member
Sawatmakal

Latest Threads

Top