Write web apps in Python?

Discussion in 'Python' started by Gilles Ganault, Apr 12, 2010.

  1. 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.
     
    Gilles Ganault, Apr 12, 2010
    #1
    1. Advertising

  2. > 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



    --
    Psss, psss, put it down! - http://www.cafepress.com/putitdown
     
    Daniel Fetchinson, Apr 12, 2010
    #2
    1. Advertising

  3. Gilles Ganault, Apr 12, 2010
    #3
  4. On 12 abr, 06:57, Gilles Ganault <> wrote:
    > 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
     
    Luis M. González, Apr 12, 2010
    #4
  5. 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
     
    Stefan Behnel, Apr 12, 2010
    #5
  6. On Mon, 12 Apr 2010 05:37:54 -0700 (PDT), Luis M. González
    <> 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.
     
    Gilles Ganault, Apr 15, 2010
    #6
  7. 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.
     
    Bruno Desthuilliers, Apr 15, 2010
    #7
  8. On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
    <> 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.
     
    Gilles Ganault, Apr 15, 2010
    #8
  9. Gilles Ganault a écrit :
    > On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
    > <> 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 !-)
     
    Bruno Desthuilliers, Apr 19, 2010
    #9
  10. Gilles Ganault

    Bryan Guest

    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. 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
     
    Bryan, Apr 20, 2010
    #10
  11. 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
    > > <> 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.

    > 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 !-)
     
    Adam Tauno Williams, Apr 20, 2010
    #11
  12. Bryan a écrit :
    > 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, Apr 20, 2010
    #12
  13. 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
    >>> <> 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...
     
    Bruno Desthuilliers, Apr 20, 2010
    #13
  14. On Tue, 2010-04-20 at 17:05 +0200, Bruno Desthuilliers wrote:
    > 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
    > >>> <> 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.
     
    Adam Tauno Williams, Apr 20, 2010
    #14
  15. Gilles Ganault

    Bryan Guest

    Bruno wrote:
    > 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
     
    Bryan, Apr 20, 2010
    #15
  16. 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.

    >>> 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.
     
    Bruno Desthuilliers, Apr 21, 2010
    #16
  17. On Wed, 2010-04-21 at 10:28 +0200, Bruno Desthuilliers wrote:
    > 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.

    > 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, Apr 21, 2010
    #17
  18. Gilles Ganault

    Paul Rubin Guest

    Bruno Desthuilliers <> writes:
    > 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.
     
    Paul Rubin, Apr 21, 2010
    #18
  19. Gilles Ganault

    Chris Rebert Guest

    On Wed, Apr 21, 2010 at 2:33 AM, Adam Tauno Williams
    <> wrote:
    > On Wed, 2010-04-21 at 10:28 +0200, Bruno Desthuilliers wrote:
    >> 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.


    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
     
    Chris Rebert, Apr 21, 2010
    #19
  20. Gilles Ganault

    Bryan Guest

    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. 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
     
    Bryan, Apr 21, 2010
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. aph
    Replies:
    4
    Views:
    429
    Peter Hansen
    Jan 14, 2006
  2. Goksie Aruna
    Replies:
    0
    Views:
    243
    Goksie Aruna
    Jul 3, 2009
  3. Dennis Lee Bieber
    Replies:
    0
    Views:
    438
    Dennis Lee Bieber
    Jul 3, 2009
  4. anonymous

    Call windows apps from web apps

    anonymous, Feb 22, 2005, in forum: ASP .Net Datagrid Control
    Replies:
    4
    Views:
    244
    anonymous
    Feb 28, 2005
  5. Richard Choate

    Web enabled apps/Thin client apps

    Richard Choate, Jul 23, 2003, in forum: ASP General
    Replies:
    2
    Views:
    314
    Chris Barber
    Jul 23, 2003
Loading...

Share This Page