Write web apps in Python?
Gilles Ganault
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.
Daniel Fetchinson
Basically, yes.
For additional info have a look at http://wiki.python.org/moin/WebProgramming
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Gilles Ganault
<fetch...@googlemail.com> wrote:
>For additional info have a look at http://wiki.python.org/moin/WebProgramming
Thanks for the link.
Luis M. González
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
Stefan Behnel
> I'd like to make sure I understand what the options are to write web
> applications in 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
Gilles Ganault
<lui...@gmail.com> wrote:
>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.
Bruno Desthuilliers
> 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.
Gilles Ganault
<bruno.42.de...@websiteburo.invalid> wrote:
>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.
Bruno Desthuilliers
> On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
> <bruno.42.de...@websiteburo.invalid> wrote:
>> 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.
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 !-)
Bryan
> 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.
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?
--
--Bryan Olson
Adam Tauno Williams
> Gilles Ganault a écrit :
> > On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
> > <bruno.42.de...@websiteburo.invalid> wrote:
> >> 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].
> > 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.
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.
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>> 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.
>
> 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.
Bruno Desthuilliers
> On Mon, 2010-04-19 at 15:15 +0200, Bruno Desthuilliers wrote:
>> Gilles Ganault a écrit :
>>> On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
>>> <bruno.42.de...@websiteburo.invalid> wrote:
>>>> 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). And you'll still have to parse
included .php files on each and every request.
>
>>> 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 !-)
> 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...
Adam Tauno Williams
> Adam Tauno Williams a écrit :
> > On Mon, 2010-04-19 at 15:15 +0200, Bruno Desthuilliers wrote:
> >> Gilles Ganault a écrit :
> >>> On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
> >>> <bruno.42.de...@websiteburo.invalid> wrote:
> >>>> 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.
> > 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...
Again, the compilation of the modules is cached. The amount of
processing required for 'import...' declines to near zero.
Bryan
> 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 ?
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.
> > 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.
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.
>
> > Many large,
> > sophisticated, high-volume web apps are in PHP.
>
> 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".
--
--Bryan
Bruno Desthuilliers
>
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.
>>> 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.
>
> 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.
>> 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 ?
>
> 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.
Adam Tauno Williams
> 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,
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.
Paul Rubin
> 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.
Chris Rebert
<awil...@whitemice.org> wrote:
> On Wed, 2010-04-21 at 10:28 +0200, Bruno Desthuilliers wrote:
>> >
>> > 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,
>
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
--
http://blog.rebertia.com
Bryan
> 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.
--
--Bryan
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>> 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.
Well, I have to admit I've only used it professionnaly for the past 6
years or so, so my knowledge may be a bit lacking...
>
>> 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.
Oh, yes ? Then why don't you use C for web programming ?-)
Tim Chase
Many large, sophisticated etc applications are written in COBOL
too. I'm sure it makes a practical web programming language
too... ;-)
-tkc
Bryan
> Bryan a écrit :
>
> > Bruno Desthuilliers wrote:
> >> 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.
>
> Well, I have to admit I've only used it professionnaly for the past 6
> years or so, so my knowledge may be a bit lacking...
Competent PHP developers know how to cache libraries and various
connections and configurations. If that's been a stumbling point if
your own work, well, again, Google is your friend.
> >> 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.
>
> Oh, yes ? Then why don't you use C for web programming ?-)
Did you forget what you argued? Had you said that PHP is impractical
for writing operating systems, I would have silently agreed. You wrote
the howler: "The PHP execution model (mostly based on CGI FWIW) tends
to be a bit unpractical for non-trivial applications".
PHP *rocks* for serious web apps. PHP is specifically designed for web
apps. PHP became a major-league programming language *soley* on its
strength and success in building web apps. Popular as PHP is, it
"tends to be a bit unpractical" for anything but web apps.
'Round here we love Python. I prefer Python to Perl or PHP even in
those languages' particular areas of specialization. Advocating for
Python does not require spreading myths about PHP.
--
--Bryan
Emile van Sebille
> 'Round here we love Python. I prefer Python to Perl or PHP even in
> those languages' particular areas of specialization. Advocating for
> Python does not require spreading myths about PHP.
You're missing the point -- set-up and tear-down overhead is involved
for both python and php cgi based web serving, and Bruno I'm sure would
concur that python in this suffers similarly. You point at exactly the
issue when you noted earlier:
Bryan> I think I see what you mean -- correct me if
Bryan> I'm wrong: You want to keep complex application
Bryan> data structures around between requests. That
Bryan> sounds appealing in terms of efficiency, but
Bryan> it's bad for scalability and robustness.
It's more than appealing -- for example, it's fact with Zope, where Zeo
adds the scalability.
Emile
Bryan
> You're missing the point -- set-up and tear-down overhead is involved
> for both python and php cgi based web serving, and Bruno I'm sure would
> concur that python in this suffers similarly.
Well I wrote, "Each has its distinguishing features -- how efficiently
a web app gets invoked is not among them. It's not a language issue."
Bruno disagreed when it comes to PHP. But obviously Bruno and I don't
communicate all that well.
--
--Bryan