web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
Easy for users to learn server-side web development without compromising functionality.
For this reason, web2py requires no installation and no configuration, has no dependencies
(except for the source code distribution, which requires Python 2.5 and its standard library modules),
and exposes most of its functionality via a Web interface, including an Integrated Development Environment
with Debugger and database interface.
web2py has been stable from day one because it follows a top-down design;
i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken
backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
web2py proactively addresses the most important security issues which plague many modern web applications, as determined by
OWASP below.
web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB.
The entire source code including sample applications and images amounts to 10.4MB.
web2py has a small footprint and is very fast. It uses the
Rocket WSGI web server developed by Timothy Farrell.
It is as fast as Apache with mod_wsgi, and supports SSL and IPv6.
web2py uses Python syntax for models, controllers, and views, but does not import models and controllers
(as all the other Python frameworks do) - instead it executes them. This means that apps can be installed,
uninstalled, and modified without having to restart the web server (even in production), and different apps
can coexist without their modules interfering with one another.
web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view,
this means that different database tables are mapped into different instances of one Table class and not into different classes,
while records are mapped into instances of one Row class, not into instances of the corresponding table class. From a practical point
of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as
in popular ORMs, which would add latency.