Python web frameworks

[joe jacob]

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.

[Jeff]

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.

[Joe Riopel]

On Nov 20, 2007 7:19 AM, joe jacob <jo********@gmail.comwrote:

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.

[Joe Riopel]

On Nov 20, 2007 8:46 AM, BartlebyScrivener <bs**********@gmail.comwrote:

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.

[Bernard]

On 20 nov, 07:19, joe jacob <[e-mail]:

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.

[Diez B. Roggisch]

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

[Thomas Wittek]

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: st*********@jabber.i-pobox.net
GPG: 0xF534E231

[Paul Boddie]

On 20 Nov, 15:42, "Diez B. Roggisch" <[e-mail]:

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

[Bruno Desthuilliers]

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

[Istvan Albert]

On Nov 20, 9:42 am, "Diez B. Roggisch" <[e-mail]:

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.

[Frank Miles]

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

[Jeff]

On Nov 20, 10:00 am, Thomas Wittek <[e-mail]:

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.

[Bruno Desthuilliers]

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.

[Joe Riopel]

On Nov 21, 2007 5:42 AM, joe jacob <jo********@gmail.comwrote:

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.

[BartlebyScrivener]

On Nov 21, 4:42 am, joe jacob <[e-mail]:

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]

On Nov 21, 12:15 am, Graham Dumpleton <[e-mail]>
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.

[Ian Bicking]

On Nov 20, 7:55 am, "Joe Riopel" <[e-mail]:

On Nov 20, 2007 8:46 AM, BartlebyScrivener <[e-mail]:

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

[SamFeltus]

"""Perhaps we need a pythonic FRONTEND. """

Should have happened years ago.

[Ian Bicking]

On Nov 22, 11:00 am, Istvan Albert <[e-mail]:

On Nov 21, 12:15 am, Graham Dumpleton <[e-mail]>
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/0...-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

[TYR]

On Nov 23, 4:22 am, SamFeltus <[e-mail]:

"""Perhaps we need a pythonic FRONTEND. """

Should have happened years ago.

Python Internet Environment: PIE.

[Jeffrey Froman]

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

[Istvan Albert]

On Nov 25, 1:55 am, Graham Dumpleton <[e-mail]>
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]

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]

On Nov 29, 2:36 am, Thomas Guettler <[e-mail]:

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

[Aaron Watters]

On Nov 22, 11:22 pm, SamFeltus <[e-mail]:

"""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/pydis...recognized+dim

[TYR]

On Nov 29, 3:15 pm, Aaron Watters <[e-mail]:

On Nov 22, 11:22 pm, SamFeltus <[e-mail]:

"""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?

[Jeffrey Froman]

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

[=?ISO-8859-1?Q?Michael_Str=F6der?=]

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]

On Dec 8, 8:26 am, Michael Ströder <[e-mail]:

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]

On Dec 9, 12:26 am, Michael Ströder <[e-mail]:

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