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

Search Discussions

  • Daniel Fetchinson at Apr 12, 2010 at 10:13 am

    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
  • Gilles Ganault at Apr 12, 2010 at 10:56 am

    On Mon, 12 Apr 2010 12:13:17 +0200, Daniel Fetchinson wrote:
    For additional info have a look at http://wiki.python.org/moin/WebProgramming
    Thanks for the link.
  • Luis M. González at Apr 12, 2010 at 12:37 pm

    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
  • Gilles Ganault at Apr 15, 2010 at 8:09 am

    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.
  • Bruno Desthuilliers at Apr 15, 2010 at 10:41 am

    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.
  • Gilles Ganault at Apr 15, 2010 at 4:19 pm

    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.
  • Bruno Desthuilliers at Apr 19, 2010 at 1:15 pm

    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 !-)
  • Bryan at Apr 20, 2010 at 11:09 am

    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
  • Bruno Desthuilliers at Apr 20, 2010 at 3:00 pm

    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.
  • Bryan at Apr 20, 2010 at 8:54 pm

    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
  • Bruno Desthuilliers at Apr 21, 2010 at 8:28 am

    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.
  • Adam Tauno Williams at Apr 21, 2010 at 9:33 am

    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.
  • Chris Rebert at Apr 21, 2010 at 10:06 am

    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
  • Paul Rubin at Apr 21, 2010 at 9:40 am

    Bruno Desthuilliers <bruno.42.desthuilliers at websiteburo.invalid> 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.
  • Bryan at Apr 21, 2010 at 1:15 pm

    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
  • Bruno Desthuilliers at Apr 21, 2010 at 1:46 pm

    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...
    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 at Apr 21, 2010 at 2:34 pm

    On 04/21/2010 08:46 AM, Bruno Desthuilliers wrote:
    Bryan a ?crit :
    Bruno Desthuilliers wrote:
    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 ?-)
    Many large, sophisticated etc applications are written in COBOL
    too. I'm sure it makes a practical web programming language
    too... ;-)

    -tkc
  • Bryan at Apr 21, 2010 at 6:37 pm

    Bruno Desthuilliers wrote:
    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 at Apr 21, 2010 at 7:09 pm
    On 4/21/2010 11:37 AM Bryan said...
    '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 at Apr 22, 2010 at 12:48 pm

    Emile van Sebille wrote:
    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
  • Adam Tauno Williams at Apr 20, 2010 at 12:40 pm

    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 !-)
  • Bruno Desthuilliers at Apr 20, 2010 at 3:05 pm

    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...
  • Adam Tauno Williams at Apr 20, 2010 at 5:36 pm

    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.
  • Stefan Behnel at Apr 12, 2010 at 12:52 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedApr 12, '10 at 9:57a
activeApr 22, '10 at 12:48p
posts25
users11
websitepython.org

People

Translate

site design / logo © 2022 Grokbase