3 ms·

I'd say the spectrum of Python web frameworks looks like this web2py -> Django -> Turbo Gears -> Pylons -> Web.py On the left you have more fully integrated f

I'd say the spectrum of Python web frameworks looks like this web2py -> Django -> Turbo Gears -> Pylons -> Web.py On the left you have more fully integrated frameworks that do more out of the box (and essentially make more choices for you upfront). On the right you have frameworks where you do most of the work yourself. These frameworks eliminate some of the boiler plate of writing a web applications and give you the responsibility of handling the rest. Which one to use depends on what you're looking for. There is no reason any of the above frameworks can't handle a "digg effect". Just throw servers at it.

dazzawazza 19y ago
I'd agree with the graph you've drawn there. I'm a big fan of TurboGears. The reason I chose it was because it sits in the middle. It does a lot of stuff for you... but you can get rid of most of it when you need to. Looking at web.py I think you'll suffer from the poor docs and the code can get a little hairy. As a simple web server you may want to check cherrypy (which under pins TurboGears). It's got a good reputation, good docs and can be deployed in a variety of ways behind apache (or many other web servers)
- mdipierro 19y ago
  This funny because when web2py started we aimed at being small like web.py. In fact the core web2py functionalities (from gluon import *) are very similar to web.py and the entire core is less the 120KB. Ocan still use it that low level and import SQLAlchemy and Mako for example (with loss of some of the higher level functionalities of course, like the database administrative interface). Anyway, I agree with Cosmin's assessment that it grew to do a lot more. The main phylosophy is that the framework should make (by default) some decisions for the user, in particular particular about things that have to do with security and persistance. At high level web2py borrowed some ideas from Django (the administrative interface and {{...}} in templates), some from Turbogears (response.flash?) and some from cherrypy (@cache).

dazzawazza 19y ago

I'd agree with the graph you've drawn there. I'm a big fan of TurboGears. The reason I chose it was because it sits in the middle. It does a lot of stuff for you... but you can get rid of most of it when you need to. Looking at web.py I think you'll suffer from the poor docs and the code can get a little hairy. As a simple web server you may want to check cherrypy (which under pins TurboGears). It's got a good reputation, good docs and can be deployed in a variety of ways behind apache (or many other web servers)

mdipierro 19y ago
This funny because when web2py started we aimed at being small like web.py. In fact the core web2py functionalities (from gluon import *) are very similar to web.py and the entire core is less the 120KB. Ocan still use it that low level and import SQLAlchemy and Mako for example (with loss of some of the higher level functionalities of course, like the database administrative interface). Anyway, I agree with Cosmin's assessment that it grew to do a lot more. The main phylosophy is that the framework should make (by default) some decisions for the user, in particular particular about things that have to do with security and persistance. At high level web2py borrowed some ideas from Django (the administrative interface and {{...}} in templates), some from Turbogears (response.flash?) and some from cherrypy (@cache).