3 ms·

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 y

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