[Chicago] web2py 1.20 is out

Massimo Di Pierro mdipierro at cs.depaul.edu
Tue Feb 5 06:15:28 CET 2008

Dear Daniel,

you were not rude to me so no need to apologize. Please call me Massimo.

For anybody who want a quickstart, I suggest the 5mins tutorial
or the long tutorial

Daniel, you actually asked a good question: Why did I develop web2py?

It was summer 2007 when I realized I had two problems:

1) my father, who is an experienced visual basic developer, wanted to  
start doing web development. Since I have developed and/or I have  
taught django, turbogears and rails, I suggested those and pushed him  
towards open source. Turned out they did not work for him because he  
had no intention to use shell scripting, learn how to configure a  
database, a web server, etc. Most importantly none of those systems  
allows to compile (or bytecode compile) applications.

2) I was going to teach a class on (the inner workings of) web  
frameworks. I am teaching the class now. I looked into Django and  
Pylons and I found both of them too complex for the task. I found  
that Pylons is rapidly evolving, but the documentation is not always  
in sync with the current version and leaves many options to the  
developer (SQLObject vs SQLAlchemy, Genshi vs Kid vs Mako, etc.).  
Students typically do not like this.

So I started writing web2py with the following goals that are now  

1) design the user API first and never break backward compatibility
2) have everything in one package with no dependencies (including  
python, web server, sqlite database, web interface, etc.)
3) enable the developer to do everything through the web interface  
(development, debugging, testing, deployment, management and database  
4) ability to byte-code compile apps.
5) ability to run from a USB drive without installation (not even of  
Python) and without configuration.
6) provide a built-in ticketing system to track ALL runtime errors  
for easy debugging.
7) fit everything in less than 1.3MB (including images, epydocs and  
other static files).

Almost all web2py code is written from scratch except the web server  
(it uses httpserver from paste, the same as pylons). I borrowed some  
ideas from Django  (form processing, admin interface, the use of  
decorators for caching), some from Turbogears (the simpler syntax for  
controllers, response.flash), some from SQLAlchemy (the syntax of the  
web2py ORM is similar to SQLAlchemy but web2py is much faster).

There are things I did not like of those frameworks, so I got rid of  
them in web2py:
1) all the tedious configuration steps. web2py has NO config files.
2) the fact that a controller needs a view. In web2py views are  
generated automatically and dynamically until the user creates one.
3) the languages using for the view/templates. web2py uses 100% pure  
python for the views without limitations with one caveat: "pass"  
closes a block so there is no indentation requirement.
4) view helpers. I think web2py helpers are more intuitive than any  
alternative. They are so intuitive that people labeled them as  
stupid. I take it as a compliment.
5) the too many choices they give to the developer (where should  
sessions be stored? should they be on or off? what is the name of a  
view associated to a controller? which url maps into a give  
controller?). web2py makes those choices and does not ask questions.  
In some cases an experienced developer can override web2py choices.
6) lack of security. For example, Django by default does not escape  
the output printed in the html. web2py validates URL, all forms  
(based on their corresponding DB field types), escapes all output  
(unless user explicitly says no).

I am sure this does not settle it and, to a great extent, which  
framework is better is not so much a technical issue as it is a  
religious issue. And, I do not wish to be  involved in a war of  

I just hope people will give web2py a try because, even if you do not  
like it, it may give you some ideas on how to improve Django and  
Pylons and make them more user friendly. It is also a great way to  
teach MVC even if you decide to go with Django or Pylons or Rails.


More information about the Chicago mailing list