Web Application Server in Python: which one to choose ?

[Graham Dumpleton]

smulloni at bracknell.smullyan.org (Jacob Smullyan) wrote in message news:<slrn9p7v7g.v6m.smulloni at smullyan.org>...
> However, my two bits are that if you want to do web development in Python
> because you want to benefit from the advantages of the Python language,
> Zope, despite its many merits, is probably not going to please you, at least
> immediately. ....
> 
> I won't go over the SkunkWeb propaganda here; you can read the FAQ and make
> up your own mind.  I do find the SkunkWeb component model perhaps the most
> Pythonic/"fits your brain" design around; I think it is brilliant in its
> versatility and almost insulting simplicity.  (I'm not being arrogant here,
> because I had nothing to do with its invention.)  SkunkWeb is a
> "less-is-more" application; you get a rather small toolkit with which you
> can be productive almost instantly and you quickly discover that you can do 
> a hell of a lot with it.  

In terms of SkunkWeb being more a toolkit, you might want to look at
OSE, which is also more along the lines of being a toolkit as opposed
to being a "be all and end all" application. I would go as far as
saying that OSE even pitches below that of SkunkWeb. OSE in fact
doesn't even have its heritage in Python but at its core is a library
of resuable C++ classes with support ranging from logging and
collections right up to event driven systems, distributed messaging
and HTTP servlets.

The Python interface is actually mostly a wrapper around aspects of
the support included in the C++ class library. Most users of OSE
actually get it and use it because of the generic C++ class library
and would never even compile or use the Python stuff. Unfortunately, I
feel this heritage is also OSE's downfall as far as getting Python
developers to adopt it, as as soon as they see it isn't pure Python
they quickly head the other direction. :-(

Anyway, something which is quite distinct with OSE is that the web
interface is a bridge into a distributed service agent framework based
on an event driven messaging system. That is, your application isn't
dependent on the web interface infrastructure and thus is more suited
to developing an application which has a web interface as an
additional feature, as opposed to one where the focus is the web
interface. In some respects the service agent framework can be likened
to Java beans, but where the services can be written in Python or C++
and be in the same process or remote processes.

Don't quite understand what I am talking about, then the Python
documentation for OSE might help. You can find this and the software
itself at:

  http://ose.sourceforge.net

There should be an update to software and documentation in the next
few weeks sometime which further extends the Python web interface to
add features often expected in such systems. The whole design is such
however, that it is easy to extend the core HTTP servlet framework to
add new features if you need extra stuff. I would hazard to say that
in this respect it is more customisable than many similar packages out
there for Python. In fact, there is an expectation that the user will
fill in certain gaps themselves rather than mandate a particular
approach to something. For example, where information is stored for
client and user authorisation. This avoids some of the problems
inherit in other systems where you have to buy into their way of doing
things.