FAQ
There are a lot of web frameworks for python like django, mod_python,
spyce, turbo gears, Zope, Cherrypy etc. Which one is the best in terms
of performance and ease of study.

Search Discussions

  • Jeff at Nov 20, 2007 at 12:42 pm
    The only one that I have used extensively is Django, which is very
    easy to use and quite powerful in the arena for which it was created.
    It has a powerful admin interface that automatically generates data
    entry forms for content producers and a decent template system. It
    has some definite drawbacks, though. The admin interface is difficult
    to customize because it was not meant to be customized too much
    (Django was written in a newspaper environment, where data needs to go
    online quickly and be easily customizable for the next story or next
    year's use). It also lacks ajax support.

    I understand that Zope has a pretty high learning curve and is
    currently in various stages of rewrite.

    I don't know much about the others. Turbo gears uses Mochikit, which
    hasn't had a new stable release in some time. I prefer jQuery myself.
  • Thomas Wittek at Nov 20, 2007 at 3:00 pm

    Jeff:
    I don't know much about the others. Turbo gears uses Mochikit, which
    hasn't had a new stable release in some time. I prefer jQuery myself.
    You can use jQuery with TurboGears if you develop custom widgets (I do so).
    No problem here.

    --
    Thomas Wittek
    Web: http://gedankenkonstrukt.de/
    Jabber: streawkceur at jabber.i-pobox.net
    GPG: 0xF534E231
  • Jeff at Nov 20, 2007 at 6:12 pm

    On Nov 20, 10:00 am, Thomas Wittek wrote:
    Jeff:
    I don't know much about the others. Turbo gears uses Mochikit, which
    hasn't had a new stable release in some time. I prefer jQuery myself.
    You can use jQuery with TurboGears if you develop custom widgets (I do so).
    No problem here.
    That's good to know, but I was intending to mean that TurboGears has
    built-in support for Mochikit, while Django has no built-in Javascript
    or Ajax support.
  • Joe Riopel at Nov 20, 2007 at 1:18 pm

    On Nov 20, 2007 7:19 AM, joe jacob wrote:
    There are a lot of web frameworks for python like django, mod_python,
    spyce, turbo gears, Zope, Cherrypy etc. Which one is the best in terms
    of performance and ease of study.
    I wouldn't classify mod_python as a web framework: "Mod_python is an
    Apache module that embeds the Python interpreter within the server.".

    I haven't used all of the frameworks that you have mentioned, but I
    really like what I have seen from Pylons so far.
  • BartlebyScrivener at Nov 20, 2007 at 1:46 pm

    On Nov 20, 6:19 am, joe jacob wrote:
    There are a lot of web frameworks for python like django, mod_python,
    spyce, turbo gears, Zope, Cherrypy etc. Which one is the best in terms
    of performance and ease of study.
    I'm looking at django mainly. I hope the veterans jump in with the
    latest on these. The django book (written by the developers) comes out
    12/7. Django comes with its own little server so that you don't have
    to set up Apache on your desktop to play with it. Configuration is
    tricky at first, but what fun to code a web app in Python instead of
    looking up php commands all day.

    Drafts of the django book are available at the site. I would follow
    the examples in the book instead of the tutorial. The tutorial works,
    but I seemed to learn more using the examples in the book.

    As for performance, see the page on caching. I barely understand the
    server dynamics but you can find pages and sites comparing dango
    performance to ruby on rails.

    http://www.djangoproject.com/documentation/cache/

    rd
  • Joe Riopel at Nov 20, 2007 at 1:55 pm

    On Nov 20, 2007 8:46 AM, BartlebyScrivener wrote:
    Django comes with its own little server so that you don't have
    to set up Apache on your desktop to play with it.
    Pylons too, it's good for development but using the bundled web server
    is not recommended for production.
  • Diez B. Roggisch at Nov 20, 2007 at 2:42 pm

    12/7. Django comes with its own little server so that you don't have
    to set up Apache on your desktop to play with it.
    I was rather shocked to learn that django only has this tiny server and does
    not come with a stand-alone server and is supposed to run as
    mod_python/cgi-driven app through apache.

    Which reaps you of all the benefits of standalone servers like connection
    pooling & caching data and so forth. Including sessions - I presume they
    always go into the db/filesystem as PHP does.

    Diez
  • Paul Boddie at Nov 20, 2007 at 3:13 pm

    On 20 Nov, 15:42, "Diez B. Roggisch" wrote:
    12/7. Django comes with its own little server so that you don't have
    to set up Apache on your desktop to play with it.
    I was rather shocked to learn that django only has this tiny server and does
    not come with a stand-alone server and is supposed to run as
    mod_python/cgi-driven app through apache.
    The standalone server aspect of a large number of Python Web
    frameworks typically involves BaseHTTPServer from the standard
    library, as far as I've seen, excluding things like Twisted which
    aspire to offer production quality server solutions themselves. This
    was common back in the old days of Webware, in contrast to Zope which
    used Medusa at the time, if I remember correctly.
    Which reaps you of all the benefits of standalone servers like connection
    pooling & caching data and so forth. Including sessions - I presume they
    always go into the db/filesystem as PHP does.
    I guess it's a compromise between deployment complexity and benefits
    in the above areas, although mod_python should offer some relief in
    some of the above areas. What people didn't like about Webware so much
    was that run in the recommended way - with a standalone server which
    communicated with Web server processes - people had to have separate
    long-running processes, which various hosting providers didn't like.

    What's most important is that you should be able to switch out one
    server technology with another when you reach the limits of the
    original, all without having to rewrite your application or do some
    major re-plumbing. It does surprise me that mod_python is recommended
    for use with Django in the various quick start guides I've read, but I
    suppose that lets the developer avoid the issue of migrating up from a
    simple server to something more scalable. Not that this should be a
    problem, of course.

    Paul
  • Istvan Albert at Nov 20, 2007 at 3:33 pm

    On Nov 20, 9:42 am, "Diez B. Roggisch" wrote:
    12/7. Django comes with its own little server so that you don't have
    to set up Apache on your desktop to play with it.
    I was rather shocked to learn that django only has this tiny server and does
    not come with a stand-alone server
    Alas it is even worse than that, the development server is single
    threaded and that can be a big problem when developing sites that make
    multiple simultaneous requests at the same time (say if one of those
    requests stalls for some reason). It is trivial to add multi threading
    via a mixin (takes about two lines of code) but it does not seem to be
    a priority to do so.

    For large traffic though, Django is better than just about anything
    other framework because it is built as multiprocess framework through
    mod_python (rather than threaded). So there is no global interpreter
    lock, thread switching etc. Django was built based in a real life
    heavy duty use scenario, and over the years that really helped with
    ironing out the problems.

    i.
  • Graham Dumpleton at Nov 20, 2007 at 9:39 pm

    On Nov 21, 2:33 am, Istvan Albert wrote:
    On Nov 20, 9:42 am, "Diez B. Roggisch" wrote:

    12/7. Django comes with its own little server so that you don't have
    to set up Apache on your desktop to play with it.
    I was rather shocked to learn that django only has this tiny server and does
    not come with a stand-alone server
    Alas it is even worse than that, the development server is single
    threaded and that can be a big problem when developing sites that make
    multiple simultaneous requests at the same time (say if one of those
    requests stalls for some reason). It is trivial to add multi threading
    via a mixin (takes about two lines of code) but it does not seem to be
    a priority to do so.

    For large traffic though, Django is better than just about anything
    other framework because it is built as multiprocess framework through
    mod_python (rather than threaded).
    This only holds if actually hosted on Apache. As Django these days
    supports WSGI interface there is nothing to stop it being run with
    other hosting solutions that support WSGI. So, you could host it under
    paster or CherryPy WSGI servers. You could even run it under CGI if
    you were really desperate using a CGI-WSGI adapter. So, it isn't
    strictly correct to say it is as a multiprocess framework specifically
    for mod_python, although the developers will admit in the first
    instance that they didn't design the internals with multithreading in
    mind. That said, there aren't believed to be any multithreading issues
    in Django itself at this time.
    So there is no global interpreter
    lock, thread switching etc.
    Use of worker MPM (multiprocess+multithreaded) in Apache in place of
    prefork MPM (multiprocess+single threaded) is also still more than
    acceptable a solution to hosting Python web applications using either
    mod_python or mod_wsgi.

    People keep pushing this barrow about the GIL and multithreading being
    a huge problem, when in the context of Apache it is isn't, at least
    not to the degree people make out. The reason for this is that when
    using worker MPM it sill acts as a multi process web server even
    though each process is also multithreaded. Within those worker MPM
    child processes there is also a lot going on that doesn't involve
    Python code nor the GIL, for example initial request process and
    serving up of static files etc.

    Result is that the Python GIL is no impediment when using Apache on
    UNIX to making good use of multiple processors or cores, even when
    Apache worker MPM is used.

    For where I have talked about this before see:
    http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html

    Graham
  • BartlebyScrivener at Nov 21, 2007 at 2:37 am

    On Nov 20, 3:39 pm, Graham Dumpleton wrote:

    This only holds if actually hosted on Apache. As Django these days
    supports WSGI interface there is nothing to stop it being run with
    other hosting solutions that support WSGI. So, you could host it under
    paster or CherryPy WSGI servers. You could even run it under CGI if
    you were really desperate using a CGI-WSGI adapter. So, it isn't
    strictly correct to say it is as a multiprocess framework specifically
    for mod_python, although the developers will admit in the first
    instance that they didn't design the internals with multithreading in
    mind. That said, there aren't believed to be any multithreading issues
    in Django itself at this time.

    People keep pushing this barrow about the GIL and multithreading being
    a huge problem, when in the context of Apache it is isn't, at least
    not to the degree people make out. The reason for this is that when
    using worker MPM it sill acts as a multi process web server even
    though each process is also multithreaded. Within those worker MPM
    child processes there is also a lot going on that doesn't involve
    Python code nor the GIL, for example initial request process and
    serving up of static files etc.

    Result is that the Python GIL is no impediment when using Apache on
    UNIX to making good use of multiple processors or cores, even when
    Apache worker MPM is used.
    I understand about a fifth of this exchange but I'm glad it's here so
    I can follow links and search on the terminology. I couldn't tell from
    earlier posts if mod_python was good or bad.

    The Django book says: "Apache with mod_python currently is the most
    robust setup for using Django on a production server."

    Is that true? And if you start small with, say, an online arts
    magazine for a metropolitan area, then can we easily scale if we
    become popular? I'm picking Django because it sounds like they did
    just this with a newspaper site in Lawrence, Kansas.

    We are thinking of starting with Webfaction and just seeing what
    happens. All I know is that I like Python and Django and would rather
    stick with open source.

    Thanks for the info.

    rd
  • Graham Dumpleton at Nov 21, 2007 at 5:15 am

    On Nov 21, 1:37 pm, BartlebyScrivener wrote:
    On Nov 20, 3:39 pm, Graham Dumpleton wrote:

    This only holds if actually hosted on Apache. As Django these days
    supports WSGI interface there is nothing to stop it being run with
    other hosting solutions that support WSGI. So, you could host it under
    paster or CherryPy WSGI servers. You could even run it under CGI if
    you were really desperate using a CGI-WSGI adapter. So, it isn't
    strictly correct to say it is as a multiprocess framework specifically
    for mod_python, although the developers will admit in the first
    instance that they didn't design the internals with multithreading in
    mind. That said, there aren't believed to be any multithreading issues
    in Django itself at this time.
    People keep pushing this barrow about the GIL and multithreading being
    a huge problem, when in the context of Apache it is isn't, at least
    not to the degree people make out. The reason for this is that when
    using worker MPM it sill acts as a multi process web server even
    though each process is also multithreaded. Within those worker MPM
    child processes there is also a lot going on that doesn't involve
    Python code nor the GIL, for example initial request process and
    serving up of static files etc.
    Result is that the Python GIL is no impediment when using Apache on
    UNIX to making good use of multiple processors or cores, even when
    Apache worker MPM is used.
    I understand about a fifth of this exchange but I'm glad it's here so
    I can follow links and search on the terminology. I couldn't tell from
    earlier posts if mod_python was good or bad.
    Version 3.3 of mod_python fixed up a lot of issues that existed with
    older versions of mod_python. There are still a lot of issues in
    mod_python unfixed.

    https://issues.apache.org/jira/browse/MODPYTHON

    In the main people will not run into these issues, of if they do, the
    incidence of them causing a direct or significant impact is low, or
    with people just tolerating the problems.

    If you want to be where hosting with Apache is heading, then look at
    mod_wsgi (http://www.modwsgi.org) instead. People will say I am biased
    because I wrote it, but I was also the main person who did the more
    recent work on fixing up mod_python and am more aware than others of
    what problems still exist in mod_python.

    To be frank, unless some white knight comes along and dives into
    mod_python and fixes up the remaining issues, then you probably will
    not see any significant future updates to mod_python and it will just
    stagnate. I certainly will not be devoting much time to mod_python any
    more.

    Part of the problem with mod_python is that the code base has grown
    over time and is long overdue for a complete rethink, which is in part
    what mod_wsgi was about, ie., making the code and configuration a lot
    simpler and safer for use in web hosting environments.

    Thus mod_wsgi takes aspects of what mod_python does, combining it with
    aspects of how FASTCGI solutions work. This gives the option of
    embedding a Python application in Apache for maximum speed, or using
    daemon processes as means of being able to better separate multiple
    applications.

    Most importantly, mod_wsgi supports WSGI directly, making it
    reasonably trivial to run any Python web framework or application
    which supports the WSGI standard.
    The Django book says: "Apache with mod_python currently is the most
    robust setup for using Django on a production server."

    Is that true?
    I would say that that is now debatable. Overall mod_wsgi is probably a
    better package in terms of what it has to offer. Only thing against
    mod_wsgi at this point is peoples willingness to accept something that
    is new in conjunction with Linux distributions and web hosting
    companies being slow to adopt new packages.

    Various people are quite happily using mod_wsgi. Users of mod_wsgi
    range from people trying to run it in memory constrained VPS systems,
    right up to major sites serving up to between 3-4 million hits a day.

    There have been a few odd things come up since the initial release
    which have since been fixed, but the core is showing itself to be very
    solid.

    Graham
  • Joe jacob at Nov 21, 2007 at 10:42 am

    On Nov 21, 10:15 am, Graham Dumpleton wrote:
    On Nov 21, 1:37 pm, BartlebyScrivener wrote:


    On Nov 20, 3:39 pm, Graham Dumpleton <Graham.Dumple... at gmail.com>
    wrote:
    This only holds if actually hosted on Apache. As Django these days
    supports WSGI interface there is nothing to stop it being run with
    other hosting solutions that support WSGI. So, you could host it under
    paster or CherryPy WSGI servers. You could even run it under CGI if
    you were really desperate using a CGI-WSGI adapter. So, it isn't
    strictly correct to say it is as a multiprocess framework specifically
    for mod_python, although the developers will admit in the first
    instance that they didn't design the internals with multithreading in
    mind. That said, there aren't believed to be any multithreading issues
    in Django itself at this time.
    People keep pushing this barrow about the GIL and multithreading being
    a huge problem, when in the context of Apache it is isn't, at least
    not to the degree people make out. The reason for this is that when
    using worker MPM it sill acts as a multi process web server even
    though each process is also multithreaded. Within those worker MPM
    child processes there is also a lot going on that doesn't involve
    Python code nor the GIL, for example initial request process and
    serving up of static files etc.
    Result is that the Python GIL is no impediment when using Apache on
    UNIX to making good use of multiple processors or cores, even when
    Apache worker MPM is used.
    I understand about a fifth of this exchange but I'm glad it's here so
    I can follow links and search on the terminology. I couldn't tell from
    earlier posts if mod_python was good or bad.
    Version 3.3 of mod_python fixed up a lot of issues that existed with
    older versions of mod_python. There are still a lot of issues in
    mod_python unfixed.

    https://issues.apache.org/jira/browse/MODPYTHON

    In the main people will not run into these issues, of if they do, the
    incidence of them causing a direct or significant impact is low, or
    with people just tolerating the problems.

    If you want to be where hosting with Apache is heading, then look at
    mod_wsgi (http://www.modwsgi.org) instead. People will say I am biased
    because I wrote it, but I was also the main person who did the more
    recent work on fixing up mod_python and am more aware than others of
    what problems still exist in mod_python.

    To be frank, unless some white knight comes along and dives into
    mod_python and fixes up the remaining issues, then you probably will
    not see any significant future updates to mod_python and it will just
    stagnate. I certainly will not be devoting much time to mod_python any
    more.

    Part of the problem with mod_python is that the code base has grown
    over time and is long overdue for a complete rethink, which is in part
    what mod_wsgi was about, ie., making the code and configuration a lot
    simpler and safer for use in web hosting environments.

    Thus mod_wsgi takes aspects of what mod_python does, combining it with
    aspects of how FASTCGI solutions work. This gives the option of
    embedding a Python application in Apache for maximum speed, or using
    daemon processes as means of being able to better separate multiple
    applications.

    Most importantly, mod_wsgi supports WSGI directly, making it
    reasonably trivial to run any Python web framework or application
    which supports the WSGI standard.
    The Django book says: "Apache with mod_python currently is the most
    robust setup for using Django on a production server."
    Is that true?
    I would say that that is now debatable. Overall mod_wsgi is probably a
    better package in terms of what it has to offer. Only thing against
    mod_wsgi at this point is peoples willingness to accept something that
    is new in conjunction with Linux distributions and web hosting
    companies being slow to adopt new packages.

    Various people are quite happily using mod_wsgi. Users of mod_wsgi
    range from people trying to run it in memory constrained VPS systems,
    right up to major sites serving up to between 3-4 million hits a day.

    There have been a few odd things come up since the initial release
    which have since been fixed, but the core is showing itself to be very
    solid.

    Graham
    Thanks everyone for the response. From the posts I understand that
    Django and pylons are the best. By searching the net earlier I got the
    same information that Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure. I referred
    the djangobook. Is pylons better in terms of performance and ease of
    study compared to Django.
  • Bruno Desthuilliers at Nov 21, 2007 at 11:25 am
    joe jacob a ?crit :
    (snip)
    Thanks everyone for the response. From the posts I understand that
    Django and pylons are the best. By searching the net earlier I got the
    same information that Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure.
    ???

    It's been a couple of years since I last used Django, but I don't
    remember any specific complexity wrt/ configuration.
  • Jeff at Nov 21, 2007 at 1:18 pm

    On Nov 21, 6:25 am, Bruno Desthuilliers <bruno. 42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    joe jacob a ?crit :
    (snip)
    Thanks everyone for the response. From the posts I understand that
    Django and pylons are the best. By searching the net earlier I got the
    same information that Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure.
    ???

    It's been a couple of years since I last used Django, but I don't
    remember any specific complexity wrt/ configuration.
    The only difficulties I have had have been with serving static media.
    Specifically, in the differences in setup between the development
    environment and production, and setting it up so that I don't have to
    make any changes to the code in order to roll out upgrades to a
    product.

    My employer (a large local newspaper) has been using Django for about
    while now. We get a decent amount of traffic and it has scaled very
    nicely. The only area where there were any problems was with our
    MySQL server; abstracting your DB code with an ORM is not as efficient
    as doing your own custom SQL, at least in terms of performance (in
    terms of development time, it certainly outweighs the performance hit
    in most cases). However, we were running quite a few sites off of
    that database at the time, and that had a lot to do with it as well.
  • Steven Bethard at Nov 21, 2007 at 5:27 pm

    Jeff wrote:
    On Nov 21, 6:25 am, Bruno Desthuilliers <bruno.
    42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    joe jacob a ?crit :
    (snip)
    Thanks everyone for the response. From the posts I understand that
    Django and pylons are the best. By searching the net earlier I got the
    same information that Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure.
    ???

    It's been a couple of years since I last used Django, but I don't
    remember any specific complexity wrt/ configuration.
    The only difficulties I have had have been with serving static media.
    Specifically, in the differences in setup between the development
    environment and production, and setting it up so that I don't have to
    make any changes to the code in order to roll out upgrades to a
    product.
    I ran into this same problem. I wish it was simply a matter of starting
    the django project on another server, but a bunch of paths and URLs
    always seem to need to be changed. (I end up having to modify my
    urls.py files because I go from being at the URL root on the development
    server to being in a subdirectory on the actual server.)

    Other that those issues though, I've really enjoyed working in Django.

    STeVe
  • Joe jacob at Nov 23, 2007 at 4:08 pm

    On Nov 21, 10:27 pm, Steven Bethard wrote:
    Jeff wrote:
    On Nov 21, 6:25 am, Bruno Desthuilliers <bruno.
    42.desthuilli... at wtf.websiteburo.oops.com> wrote:
    joe jacob a ?crit :
    (snip)
    Thanks everyone for the response. From the posts I understand that
    Django and pylons are the best. By searching the net earlier I got the
    same information that Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure.
    ???
    It's been a couple of years since I last used Django, but I don't
    remember any specific complexity wrt/ configuration.
    The only difficulties I have had have been with serving static media.
    Specifically, in the differences in setup between the development
    environment and production, and setting it up so that I don't have to
    make any changes to the code in order to roll out upgrades to a
    product.
    I ran into this same problem. I wish it was simply a matter of starting
    the django project on another server, but a bunch of paths and URLs
    always seem to need to be changed. (I end up having to modify my
    urls.py files because I go from being at the URL root on the development
    server to being in a subdirectory on the actual server.)

    Other that those issues though, I've really enjoyed working in Django.

    STeVe- Hide quoted text -

    - Show quoted text -
    Thanks everyone for the response. I installed Django and configured
    apache to execute the python scripts. I am learning it now.
  • Sells, Fred at Nov 21, 2007 at 1:14 pm
    -snip--
    Thanks everyone for the response. From the posts I understand that
    Django and pylons are the best. By searching the net earlier I got the
    same information that Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure. I referred
    the djangobook. Is pylons better in terms of performance and ease of
    study compared to Django.
    --
    I too was confused by the setup, but I got help from the django site and found it was worth the effort. I'm also not too experienced at web "stuff" with python FWIW.
  • Joe Riopel at Nov 21, 2007 at 1:23 pm

    On Nov 21, 2007 5:42 AM, joe jacob wrote:
    Thanks everyone for the response. From the posts I understand that
    Django and pylons are the best. By searching the net earlier I got the
    same information that Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure. I referred
    the djangobook. Is pylons better in terms of performance and ease of
    study compared to Django.
    I have only used Pylons for the simplest of applications (Not because
    I don't think it can handle complex applications, but because I am
    trying to learn the framework) and find it very easy to configure.
    That said, I think it's definitely worth your time to to either give
    Pylons a try, or give Django more time.

    This thread has been going for only a few days now, and I wouldn't
    expect you'd have very intimate knowledge with any framework.
  • Sells, Fred at Nov 21, 2007 at 1:25 pm
    slight shift of topic here.

    I'm a newbie at standard web stuff. Mostly java webstart and a little mod_python.

    I experimented with Adobe Flex and really loved it for doing the front end. The backend needs to provide xml, json or AMF (an adobe proprietary binary format). For prototyping, I was able to put xml or json responses in text files and used that to work out the UI and do some cool demos. But I never got past prototyping, getting stuck in the "which python webfamework is best" mobius loop.

    My Question: Does anyone have experience with Flex+Python and especially with Adobe's AMF. I've got some time to try to setup a "standard" and am a bit short on hands-on experinece.
  • BartlebyScrivener at Nov 21, 2007 at 4:56 pm

    On Nov 21, 4:42 am, joe jacob wrote:
    Django is best among the frameworks so I
    downloaded it and I found it very difficult to configure. I referred
    the djangobook.
    It's not a turnkey type thing like WordPress or Joomla. It's a
    webframework. Also watch versions. The book examples work only in .
    96. It's easy in the tutorial to stray into docs for .95 or SVN. I
    think that's part of the confusion.

    rd
  • Istvan Albert at Nov 22, 2007 at 5:00 pm

    On Nov 21, 12:15 am, Graham Dumpleton wrote:

    I would say that that is now debatable. Overall mod_wsgi is probably a
    better package in terms of what it has to offer. Only thing against
    mod_wsgi at this point is peoples willingness to accept something that
    is new in conjunction with Linux distributions and web hosting
    companies being slow to adopt new packages.
    Yes that is to be expected, many people want someone else to pay the
    early adopter's costs. Nonetheless mod_wsgi seems like the right
    direction to move the python world.

    One confounding factor that may slow its adoption could be the need of
    running plain old CGI in an efficient way. I'm not sure how that fits
    into the WSGI picture.

    i.
  • Graham Dumpleton at Nov 22, 2007 at 9:49 pm

    On Nov 23, 4:00 am, Istvan Albert wrote:
    On Nov 21, 12:15 am, Graham Dumpleton wrote:

    I would say that that is now debatable. Overall mod_wsgi is probably a
    better package in terms of what it has to offer. Only thing against
    mod_wsgi at this point is peoples willingness to accept something that
    is new in conjunction with Linux distributions and web hosting
    companies being slow to adopt new packages.
    Yes that is to be expected, many people want someone else to pay the
    early adopter's costs. Nonetheless mod_wsgi seems like the right
    direction to move the python world.

    One confounding factor that may slow its adoption could be the need of
    running plain old CGI in an efficient way. I'm not sure how that fits
    into the WSGI picture.
    Do note that using mod_wsgi doesn't preclude you still running plain
    old CGI scripts using mod_cgi or mod_cgid. As to making it more
    efficient, one can go two paths on this.

    The preferred path would be to put in the effort to convert the Python
    CGI application to WSGI. If one still needs to run it as CGI with
    other hosting solutions, then use a CGI-WSGI adapter.

    Second, albeit a bit of a kludge, just like mod_python.cgihandler is a
    kludge, is to emulate the CGI environment on top of WSGI. This would
    work if using single threaded Apache prefork MPM, or using mod_wsgi
    daemon mode with multiple processes but where each is single threaded.
    It wouldn't be practical though to do it for multithread Apache worker
    MPM, or multithreaded daemon processes with mod_wsgi daemon mode.
    Because of how Python leaks environment variables between sub
    interpreters, you would also only want to be running one sub
    interpreter within a process. This would be fine if using mod_wsgi
    daemon mode as different CGI scripts could be delegated to run in
    different daemon processes as necessary to keep them separate, but may
    not be practical if using embedded mode if hosting a range of other
    WSGI applications at the same time in embedded mode.

    So, it is doable, but effort would be better off expended at least
    converting the Python CGI script to WSGI instead. It would save a lot
    of trouble in the long run, especially with CGI scripts which weren't
    designed to be run multiple times in same memory context, ie., where
    they don't clean up after themselves.

    If someone really wanted to host an existing CGI script under WSGI
    where the same process was used over and over, and had good reasons
    for doing so, it wouldn't be hard for me to come up with a workable
    adapter that allowed it.

    Graham
  • TYR at Nov 22, 2007 at 10:47 pm
    Perhaps we need a pythonic FRONTEND.

    If you're meant to be able to run java code in a browser vm; and
    flash; and javascript...why not a reduced version of python?

    I'm thinking a sandboxed interpreter, perhaps based on EmbeddedPython,
    and a restricted set of classes; core logic, string and maths, some
    good graphics stuff (perhaps similar to nodebox), SSL support,
    filesystem access to a cache, network, xml, soap support. A standard
    model for development defining graphic entities on one hand, and
    controls on the other that the graphics are bound to. Perhaps a single
    class for "RemoteControls" covering web service calls intended to be
    bound to a graphical entity at one end and a mod_python function at
    the other?

    Force pre-compiling into .pyc; include an app to do interactive
    interpreter in a browser and some basic IDE functions with each plugin
    download.
  • SamFeltus at Nov 23, 2007 at 4:22 am
    """Perhaps we need a pythonic FRONTEND. """

    Should have happened years ago.
  • TYR at Nov 23, 2007 at 11:15 am

    On Nov 23, 4:22 am, SamFeltus wrote:
    """Perhaps we need a pythonic FRONTEND. """

    Should have happened years ago.
    Python Internet Environment: PIE.
  • Aaron Watters at Nov 29, 2007 at 3:15 pm

    On Nov 22, 11:22 pm, SamFeltus wrote:
    """Perhaps we need a pythonic FRONTEND. """

    Should have happened years ago.
    It did. Mark Hammond embedded Python under MSIE about
    the same time javascript and java applets came along (94, maybe?)
    It didn't fly because of political and marketing problems,
    I think. One technical killer was that C-Python can
    be crashed relatively easily by malicious code, and
    browser providers don't like that too much. Also, the
    stuff you need to do to make it crash proof would make
    the interpreter a lot slower (which may be why javascript
    is pretty slow).

    -- Aaron Watters

    ===
    http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=msie+de-facto+recognized+dim
  • TYR at Nov 29, 2007 at 4:43 pm

    On Nov 29, 3:15 pm, Aaron Watters wrote:
    On Nov 22, 11:22 pm, SamFeltus wrote:

    """Perhaps we need a pythonic FRONTEND. """
    Should have happened years ago.
    It did. Mark Hammond embedded Python under MSIE about
    the same time javascript and java applets came along (94, maybe?)
    It didn't fly because of political and marketing problems,
    I think. One technical killer was that C-Python can
    be crashed relatively easily by malicious code, and
    browser providers don't like that too much. Also, the
    stuff you need to do to make it crash proof would make
    the interpreter a lot slower (which may be why javascript
    is pretty slow).

    -- Aaron Watters

    ===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=msie+de-facto+...
    Time for another go, perhaps, seeing as the web has become the world's
    default user interface?
  • Graham Dumpleton at Nov 25, 2007 at 6:55 am

    On Nov 23, 8:49 am, Graham Dumpleton wrote:
    On Nov 23, 4:00 am, Istvan Albert wrote:


    On Nov 21, 12:15 am, Graham Dumpleton <Graham.Dumple... at gmail.com>
    wrote:
    I would say that that is now debatable. Overall mod_wsgi is probably a
    better package in terms of what it has to offer. Only thing against
    mod_wsgi at this point is peoples willingness to accept something that
    is new in conjunction with Linux distributions and web hosting
    companies being slow to adopt new packages.
    Yes that is to be expected, many people want someone else to pay the
    early adopter's costs. Nonetheless mod_wsgi seems like the right
    direction to move the python world.
    One confounding factor that may slow its adoption could be the need of
    running plain old CGI in an efficient way. I'm not sure how that fits
    into the WSGI picture.
    Do note that using mod_wsgi doesn't preclude you still running plain
    old CGI scripts using mod_cgi or mod_cgid. As to making it more
    efficient, one can go two paths on this.

    The preferred path would be to put in the effort to convert the Python
    CGI application to WSGI. If one still needs to run it as CGI with
    other hosting solutions, then use a CGI-WSGI adapter.

    Second, albeit a bit of a kludge, just like mod_python.cgihandler is a
    kludge, is to emulate the CGI environment on top of WSGI. This would
    work if using single threaded Apache prefork MPM, or using mod_wsgi
    daemon mode with multiple processes but where each is single threaded.
    It wouldn't be practical though to do it for multithread Apache worker
    MPM, or multithreaded daemon processes with mod_wsgi daemon mode.
    Because of how Python leaks environment variables between sub
    interpreters, you would also only want to be running one sub
    interpreter within a process. This would be fine if using mod_wsgi
    daemon mode as different CGI scripts could be delegated to run in
    different daemon processes as necessary to keep them separate, but may
    not be practical if using embedded mode if hosting a range of other
    WSGI applications at the same time in embedded mode.

    So, it is doable, but effort would be better off expended at least
    converting the Python CGI script to WSGI instead. It would save a lot
    of trouble in the long run, especially with CGI scripts which weren't
    designed to be run multiple times in same memory context, ie., where
    they don't clean up after themselves.

    If someone really wanted to host an existing CGI script under WSGI
    where the same process was used over and over, and had good reasons
    for doing so, it wouldn't be hard for me to come up with a workable
    adapter that allowed it.
    I had a play with this and got an initial solution working. It allows
    mod_wsgi to be pointed at a directory of existing unmodified Python
    CGI scripts and it will run them, maintaining the code for the CGI
    script in memory between requests. One doesn't even have to rename
    scripts to have a .py extension or follow Python module naming
    conventions like mod_python required with its CGI handler.

    Now, where as CGI script would run say at 10 requests per second for a
    simple hello world program, using mod_wsgi to manage the CGI scripts
    one could achieve 450+ requests per second with embedded mode of
    mod_wsgi, and 250+ requests per second with daemon mode. Not as quick
    as what can be achieved for an equivalent WSGI specific version of the
    script, which runs at 900+ requests per second for embedded mode and
    500+ requests for daemon mode, but still a lot better than a plain old
    CGI script which requires a new process for each request.

    One would still need to see how it works for more complicated Python
    CGI scripts. Also may need to be tweaked to allow one to configure its
    behaviour to suit the CGI script. For example, should additional
    modules imported by the script be deleted out of sys.modules when done
    or preserved for next request. Similarly, should the globals and/or
    locals of the script be preserved between requests. Whether one would
    need to adjust such behaviour would depend on the nature of the
    specific CGI script.

    The other question is whether there is even a demand for this. Do
    people want to be able to take unmodified Python CGI scripts and try
    to run them persistently in this way, or would they be better off
    converting them to proper WSGI applications.

    Graham
  • Jeffrey Froman at Nov 26, 2007 at 4:00 pm

    Graham Dumpleton wrote:

    The other question is whether there is even a demand for this. Do
    people want to be able to take unmodified Python CGI scripts and try
    to run them persistently in this way, or would they be better off
    converting them to proper WSGI applications.
    I would personally be interested in such an adapter. While recently
    considering whether to re-write a standalone mod_python application as CGI
    or WSGI, I was scared off by this paragraph from PEP333:

    -------------------------------------
    Note: although we refer to it as an "application" object, this should not be
    construed to mean that application developers will use WSGI as a web
    programming API! It is assumed that application developers will continue to
    use existing, high-level framework services to develop their applications.
    WSGI is a tool for framework and server developers, and is not intended to
    directly support application developers.
    -------------------------------------

    Do you have any thoughts about this warning? I'd much rather have the
    performance of mod_wsgi for my application, so if you can provide any
    mollifying views about WSGI's suitability for standalone applications my
    first choice would be to use WSGI directly.

    Regardless of its appropriateness for new applications, a CGI/WSGI adapter
    would still be useful for third-party CGI scripts that I have no interest
    in rewriting myself, as well as for the interim period during which my own
    CGI applications are being rewritten. It would be advantageous for the
    hosting company I work for, for example, to be able to boast that "your
    python CGI scripts run faster on our mod_wsgi-enabled servers."


    Thank you,
    Jeffrey
  • Jeffrey Froman at Dec 7, 2007 at 11:00 pm

    Jeffrey Froman wrote:

    While recently
    considering whether to re-write a standalone mod_python application as CGI
    or WSGI, I was scared off by this paragraph from PEP333:
    <snip scary warning about using WSGI as an application API>

    As a followup, I did go ahead and convert my CGI handler to WSGI, and doing
    so was not difficult at all. The steps were basically:

    1. accept environ and start_response parameters in the handler's __init__
    2. return output from __iter__ instead of writing it to stdout.
    3. pass environ and wsgi.input to the cgi.FieldStorage() parser.

    I'd still be interested in a mod_wsgi wrapper for 3rd-party CGI scripts.


    Thank you,
    Jeffrey
  • Michael Ströder at Dec 8, 2007 at 1:26 pm

    Jeffrey Froman wrote:
    I'd still be interested in a mod_wsgi wrapper for 3rd-party CGI scripts.
    I doubt that this is possible, not because of the interface. But
    conventional CGI scripts are implemented with the assumption of being
    stateless. You would have to completely reinitialize them for each hit.
    Without knowledge about the internal CGI script processing this would
    mean reinitializing the whole Python run-time environment. So IMHO
    there's no real gain. Just my 2 c.

    Ciao, Michael.
  • Istvan Albert at Dec 8, 2007 at 4:34 pm

    On Dec 8, 8:26 am, Michael Str?der wrote:

    But conventional CGI scripts are implemented with the assumption of being
    stateless.
    while it might be that some CGI scripts must be executed in a new
    python process on each request, common sense and good programming
    practices would steer most people away from that sort of approach.

    after all such CGI scripts would not execute properly under mod_python
    either

    i.
  • Graham Dumpleton at Dec 8, 2007 at 9:10 pm

    On Dec 9, 12:26 am, Michael Str?der wrote:
    Jeffrey Froman wrote:
    I'd still be interested in a mod_wsgi wrapper for 3rd-party CGI scripts.
    I doubt that this is possible, not because of the interface. But
    conventional CGI scripts are implemented with the assumption of being
    stateless. You would have to completely reinitialize them for each hit.
    Without knowledge about the internal CGI script processing this would
    mean reinitializing the whole Python run-time environment. So IMHO
    there's no real gain. Just my 2 c.
    One doesn't necessarily need to reinitialise the whole Python run time
    environment. The hack that mod_python uses is to remember what Python
    modules had been loaded before first request. At the end of the
    request it will delete from sys.modules anything that was added since
    the beginning of the request. It also replaces os.environ in its
    entirety at the start of each request as well.

    Yes, it may not still work for all CGI scripts, eg., C extension
    modules may be a problem, but may be adequate for many. In fact, for
    some class of CGI scripts, deleting all those modules from sys.modules
    may not be necessary, provided you at least cause the main CGI script
    file to at least be reinterpreted/reimported. What degree of cleaning
    out the environment could be a configurable parameter of the WSGI/CGI
    bridge.

    So, although it can be done, it is the need to use strange hacks like
    this that means it may just be better to convert CGI script to work as
    WSGI, as more guarantee of success.

    Graham
  • Istvan Albert at Nov 27, 2007 at 8:20 pm

    On Nov 25, 1:55 am, Graham Dumpleton wrote:

    The other question is whether there is even a demand for this. Do
    people want to be able to take unmodified Python CGI scripts and try
    to run them persistently in this way, or would they be better off
    converting them to proper WSGI applications.
    I think CGI will be with us for many decades.

    It will be awesome if mod_wsgi can run CGI without invoking python on
    each access.

    i.
  • Thomas Guettler at Nov 28, 2007 at 3:36 pm

    Istvan Albert schrieb:
    It will be awesome if mod_wsgi can run CGI without invoking python on
    each access.
    For SCGI there is something like this: cgi2scgi: it is small executable written in C,
    which connects to a running SCGI server.

    Executing this small binary on every request is no big overhead.

    Nevertheless I never used it.
  • Graham Dumpleton at Nov 28, 2007 at 10:58 pm

    On Nov 29, 2:36 am, Thomas Guettler wrote:
    Istvan Albert schrieb:
    It will be awesome ifmod_wsgican run CGI without invoking python on
    each access.
    For SCGI there is something like this: cgi2scgi: it is small executable written in C,
    which connects to a running SCGI server.

    Executing this small binary on every request is no big overhead.

    Nevertheless I never used it.
    That isn't the same as what is being talked about here with unmodified
    CGI scripts running under mod_wsgi. That program you are talking about
    is more in line with what Ian was talking about, but would still
    require the CGI script to be converted to work with SCGI directly or
    WSGI and then use a SCGI/WSGI adapter.

    Graham
  • Ian Bicking at Nov 23, 2007 at 4:50 am

    On Nov 22, 11:00 am, Istvan Albert wrote:
    On Nov 21, 12:15 am, Graham Dumpleton wrote:

    I would say that that is now debatable. Overall mod_wsgi is probably a
    better package in terms of what it has to offer. Only thing against
    mod_wsgi at this point is peoples willingness to accept something that
    is new in conjunction with Linux distributions and web hosting
    companies being slow to adopt new packages.
    Yes that is to be expected, many people want someone else to pay the
    early adopter's costs. Nonetheless mod_wsgi seems like the right
    direction to move the python world.

    One confounding factor that may slow its adoption could be the need of
    running plain old CGI in an efficient way. I'm not sure how that fits
    into the WSGI picture.
    Practically running CGI quickly is hard. All of the modern batch of
    frameworks contain too much code to do this; the startup cost of
    loading all that code for each request is just too much.

    For commodity servers that only support CGI scripts, and periodically
    kill long-running requests, I had an idea for making WSGI applications
    look like CGI scripts:
    http://blog.ianbicking.org/2007/08/03/fast-cgi-that-isnt-fastcgi/ --
    basically using the CGI script as a pipe to the application, with some
    process management built in.

    Of course, it still would need to be implemented. I suspect it would
    be a fairly simple task for someone familiar with C.

    This isn't really a big deal for most professional web developers, who
    can control their server environment, but lack of this style of
    deployment does make it a lot harder for web application users to use
    Python applications.

    Ian
  • BartlebyScrivener at Nov 23, 2007 at 5:29 pm
    I'm just learning Django and feeling my way through all of this server
    terminology. Where does Django's memcached feature fit into all of
    this? When you all speak of start up costs and memory intensive
    loading for each requests, doesn't the caching feature eliminate most
    of that overhead?

    http://www.djangoproject.com/documentation/cache/

    I'm probably mixing appliances and oragutans but just curious about
    how you experts feel about Django's caching.

    rd
  • Jan Claeys at Nov 26, 2007 at 12:25 am

    Op Fri, 23 Nov 2007 09:29:38 -0800, schreef BartlebyScrivener:

    I'm just learning Django and feeling my way through all of this server
    terminology. Where does Django's memcached feature fit into all of this?
    When you all speak of start up costs and memory intensive loading for
    each requests, doesn't the caching feature eliminate most of that
    overhead?
    It helps a lot for data or content that is dynamically generated from
    database queries, but doesn't change too frequently.
    http://www.djangoproject.com/documentation/cache/

    I'm probably mixing appliances and oragutans but just curious about how
    you experts feel about Django's caching.
    I'm not an "expert", but I think Django's caching framework and the
    caching middleware are great. :)


    --
    JanC
  • Ian Bicking at Nov 22, 2007 at 7:53 pm

    On Nov 20, 7:55 am, "Joe Riopel" wrote:
    On Nov 20, 2007 8:46 AM, BartlebyScrivener wrote:

    Django comes with its own little server so that you don't have
    to set up Apache on your desktop to play with it.
    Pylons too, it's good for development but using the bundled web server
    is not recommended for production.
    It's actually fine to use it for production. There's two servers that
    are used commonly with Pylons, the one in Paste and the CherryPy
    server (it's a one-line configuration change to switch). The
    generally recommended production deployment is using one of these,
    with another HTTP server in front proxying requests back. There's
    lots of side-benefits to that particular setup, like hosting the
    Pylons app alongside static files, PHP, etc. But there's quite a few
    people who serve directly from Python (probably more often using the
    CherryPy server, though I don't really know the differences in a
    production situation).

    Anyway, mostly an aside for choosing a framework.

    Ian
  • Bernard at Nov 20, 2007 at 2:30 pm

    On 20 nov, 07:19, joe jacob wrote:
    There are a lot of web frameworks for python like django, mod_python,
    spyce, turbo gears, Zope, Cherrypy etc. Which one is the best in terms
    of performance and ease of study.
    I'm making web apps with CherryPy at work and it's quite good.
    the official docs are a bit messy though but they left useful comments
    in their code.
  • Bruno Desthuilliers at Nov 20, 2007 at 3:17 pm

    joe jacob a ?crit :
    There are a lot of web frameworks for python like django, mod_python,
    spyce, turbo gears, Zope, Cherrypy etc. Which one is the best in terms
    of performance and ease of study.
    As far as I'm concerned, the winners are Django and Pylons (my own
    preference going to Pylons).
  • Frank Miles at Nov 20, 2007 at 4:04 pm

    On Tue, 20 Nov 2007, joe jacob wrote:

    There are a lot of web frameworks for python like django, mod_python,
    spyce, turbo gears, Zope, Cherrypy etc. Which one is the best in terms
    of performance and ease of study.
    Personally I found zope/plone to be very much its own enormously complex world.
    Performance was quite sluggish on a less-than-state-of-the-art computer. Part
    of my problem was that my particular job didn't really fit with the particular
    viewpoint (way of handling data) implicit in these programs. This might not
    be the case for you - you'll have to evaluate that for yourself.

    In the end I went with Django (hosted by mod_python/apache). Django thankfully
    doesn't require that you use their "admin" as the access point for normal users,
    though that means it will take more time and thought. It's still comparatively
    flexible and straightforward in comparison to zope/plone. There are a few things
    that I am not 100% satisifed with, but overall I have found django to be very
    adaptible to my particular needs. All this despite the fact that this is a
    pretty minor part of my work - I am pretty much a newby at developing for the web.

    BTW the book - while still apparently not fully completed - is available for
    free on the 'net.

    -f

Related Discussions

People

Translate

site design / logo © 2022 Grokbase