Python web developpement: the dilemma / Act 2

Posted on by

After a long trip around the Python web developpement tools, it’s time to fix. In a previous post (please read all comments before ..) we have talk for a long time about various web frameworks. Here is my personnal conclusion:

  • A web framework has nothing to do with templates. It need to allow to wrap templates easily, but it should’nt deal with them directly. (I have done DTML in a past life.. no thanks:)
  • A web framework has nothing to deal w/ the object-store. It should let me store objects as i want (without too much pain)

In the previous post we talk about the different approach: Threads, Mod_Python, Twisted, and Fork (in comments)

I have tested quite a bunch of framework right now, all have some nice feature, and drawback. To conclude my tour and explain my choice, some little points:

Webware

I really enjoy Webware, because the API is really easy learn, and work like a charm. But as explain before, I have too much trouble w/ the threads in.. I hope cheetah will cleanup the way it includes Kits.. a long thread on the mailing list.

Mod_Python

I don’t like the mod_python Publisher etc etc, I feal too close-to-apache. So i guess the I will choose MP Servlets. Performance are really good, and doesn’t need to maintain a server process on the host. This is good news because i want to host a couple of little websites. The major drawback is that there is no way to maintain (or even limit) a pool of objects between request. (without apache tweak) Another bad point is that debugging is awfull, need to restart all the time ..
But mod_python offer a lot for deployement..

Twisted

This is the most flamewar subject, I ever seen on the Python community. I used twisted, and yes it’s really fun and powerfull. But I don’t want to mix deferred and threads (for DB .. and others stuffs). If I want to mix differents networks stuffs, twisted is my tool. but as previouly said (comments) I ‘m not really fuent with twisted.web

Skunk-Web

Hum, this is a fork based server.. I haven’t tested it a lot because it’s really template base, and I want to use Cheetah or ZPT not another-templating-o-matic. And fork, may cause issue if you have some hits (but skunk really seems to work well under heavy load so.. )

And now..

So, yes, i haven’t choose one of this. In fact, in the previous post somebody ask me about Quixote, so i decided to test it. And I found an interesting stuff,
Quixote use: scgi (mod_scgi + daemon), old-fashion-cgi or mod_python, medusa or twisted.

So I can:

  • use mod_python in production area. (nothing more than apache :)
  • use mod_scgi if i want to run the server as a different user. No need to use su-exec or fight w/ ownerships…
  • use medusa to develop. And that’s a really good point because i can use pdb to debug,and avoid to restart mod_python again and again.
  • use old-fashion-cgi on system that only provides this..
  • test Durus + Dulcinea for the fun.

There is some drawbacks of course:

  • really small documentation right now (check the Quixote Wiki)
  • I don’t really like the way it map the URL namespace to the modules
  • come w/ custom templating system, but cheetah has a handler (infos in the wiki)

As Phil said: This is your new toy, until the next.

He’s right. I dream one day, Python web’s framework will be more unified. Quixote is a good example of what power we can achieve if the framework cover a large amount of different approach in a unified way.



Related Posts

18 thoughts on “Python web developpement: the dilemma / Act 2”

  1. SkunkWeb is actually not as bound to its templates as it might seem. I was confused by this too — I think the documentation is very focused on the templates, but if you ignore those parts you might start seeing how it can work without them.

    I’ve started looking at mod_python for some more advanced Apache development, but it still scares me for a full application. Generally I think of Apache as a fail-safe application that I don’t have to worry about. I fear (though this may be unfounded) that mod_python could make Apache unstable. I certainly don’t want to restart Apache because my application messed up the Python interpreter, but it seems like that can happen.

  2. I’m ok with you Ian, Apache is quite rock-solid app. I found some issues with Apache2 but fixed right now. Mod_python really seems to be stable, even on really heavy load. But yes, I think we should look what happend when an interpreter ooops, segfault or other.

    In the other hand, having to monitor only one app isn’t too much hard, but monitoring a bunch of differents servers can be a bit painfull.

  4. Except that recent posts on twisted.web mailing list say that Twisted doesn’t feet very well in WSGI.. so no support in a near future (hum not definitive right now but .. )

    – Bye Bye

  5. Give CherryPy(2) a try. It’s very light-weight, treats your web applications as, yes, applications, and stays out of the way in regards to templating engines, object stores and the likes.

  6. Twisted isn’t nearly as flamebaity as, say, decorators, or even ternary operators >:)

    There is actually a Twisted WSGI implementation already (or as close to one as you can be before PEP 333 is finalized).  However, your characterization may be accurate for all intents and purposes: WSGI applications need to be written quite carefully or in a particular way to be runnable in the single-process/single-threaded/persistent mode (one of 8 modes WSGI mandates).  Applications written for any of the other 7 configurations likely will not work well when run with twisted.web.

  7. The recent Twisted talk on WSGI is really about WSGI supporting Twisted applications, not the Twisted server. I think everyone is fairly comfortable with the server part, but writing portable asynchronous applications is up in the air, and very possibly won’t be supported by WSGI 1.0.

  8. Hi :-)
    I posted a comment in here a while ago when you were talking about web stuff. Have a look at this:

    http://www.myghty.org/

    It has a few bugs right now, but for the most part it just works, and makes it a piece of cake to write certain types of pages.

  9. I’ve had a good experience CherryPy, Cheetah and SQLObject together. Even though the three products are separate technically, they work surprisingly well together.

  13. Web development frameworks should offer the following:
    • Be OO, most importantly that means extendable through inheritance and polymorphic.
    • server independance
    • the ability to isolate the progamming code from the markup language.
    • If it offers templating it should be in a makrup language already used by designers – not porgrammers.
    • open source
    • simple
    • and already using in serious production enviroments.

    We developed Python Service Objects (pso) for the following reasons:

    1. We wanted to develop web systems that would work as cgi and mod_python request handlers on apache or nsapi handlers on netscape without thinking about httpd implementation details. To do this pso includes the class SerivceRequest that is a bridge between the server and any code we develop. This bridge also gives us a consistent and easy interface with the server and the client.
    2. We needed a fast and easy to use parser to extract sgml ( that includes html and xml) tags and replace them with the result of a rendered object. We wanted to take designed market up pages and embed them with power but not source code. We also wanted to parse the templates only once and render the object tree as we needed. The pso parser if fast and simple, returning a object tree that is easily rendered or processed by a visitor pattern.
    3. We wanted to be able to just add a new tag to a template and drop in the relevant classes without changing the application code. Every tag represents an object whose class can be sub classed. You only need to place the new class in the python import path for it to be recognized and used by the parser.
    4. We found that it was only trivial systems that did not need session handling. When you use pso, session handling is available by default.
    5. We wanted lots of useful methods to handle redirection, setting cookies, targets, status, also methods to handle file uploads, and other form handling, and url coding. pso offers these.

    We are programmers, so pso has been kept simple and basic. The template system offers no built in tags, you have to build your own or subclasses those contributed, by ourselves or other users. We decided on this spartan approach on the basis that by keeping pso simple and light it would be easier to maintain and keep error free. Who uses pso ? New York Stock Exchange, European PArliament, Ericsson, a very big fixed income intertrading concern, some rather nasty .gov agencys.

    • CherryPy is really fine, but it doesn’t meet my needs for production stage. But should feet fine w/ some projects.
    • spyce really looks like a template system than a web framework.
    • PSO looks interesting and seems to use the same basis as Quixote: A common request handler. Quixote seems to be a bit more handfull because it support twisted or medusa. And I’m quite ok w/ the fact that Quixote isn’t OO oriented (OO would be better)

    – Enjoy

  15. I have been using mod_python servlets + ZPT + sqlobject for while now, and  would recommend it to everybody

  17. Spyce is more than suitable for most applications

    Unfortunatly the docs give a bad first Impression

    After a Iittle effort I am now re-making some sites using spyce to see how it performs

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>