Web.py, the brainchild of Aaron Swartz, who developed it while working at Reddit.com, describes itself as a "minimalist's framework." Web.py employs few abstraction layers. In most cases, when you build a Web application in Web.py, you operate one level away from the actual infrastructure of databases, HTTP requests, and HTML input forms. You won't find wizards or boilerplate websites in Web.py. New websites must be built from scratch.
In addition, Web.py provides no administration utility. That means, among other things, you must rely on the back-end administration tools to create the database and tables that your application will use.
Installation is simply a matter of unzipping an archive file, followed by executing a setup script. The framework has no dependencies on external packages or libraries that must be separately downloaded. Web.py includes its own Web server, but documentation warns that it is only suitable for development work. Nevertheless, the provided server has useful debug features that are automatically enabled. For example, code changes are automatically reloaded. In addition, when an error is thrown, the Web server will produce a Web page with full error tracing information. Web.py applications can be deployed to any Web server that supports WSGI. The Web.py website suggests LightTPD or Apache.
Web.py supports most of the well-known RDBMS systems, including PostgreSQL, MySQL, SQLite, Oracle, and Microsoft SQL Server. It provides a class for abstracting access to the database, but not to the extent that database entities are represented as objects. Rather, Web.py hides the details of working with different databases. Web.py creator Swartz contends that his years of working with ORMs has taught him that, once you get beyond simple applications, you "run up against some fact about databases that the ORM has tried to hide ... and you have to go back to thinking about the database directly."
Web.py: Closer to the app
As a result, Web.py's abstractions try to "follow the grain" of the real world, rather than represent a database as something that it is not. Put simply, when you query the database, Web.py makes it obvious that you are doing so. Web.py's database class provides methods for all the familiar operations -- insert, query, update, delete -- plus functions that permit the developer to manipulate SQL directly, if need be. The framework also provides a transaction method that handles commits, rollbacks, and nested transactions.
Web.py uses a straightforward scheme to map URLs to handler code. At the beginning of each application is a specific tuple that associates URL patterns to application classes. When an HTTP request is received, the framework simply iterates through the tuple, locating the first matching pattern and dispatching the request to the associated class's
POST() method. The mechanism also provides a means of extracting any parameters that may be attached to the request and passing those parameters as arguments to the request handling routine.
Typically, all of the URL processing and request handling code fits in a single module. But when an application grows in complexity, you can split it into "sub-applications" and distribute the incoming requests. By this technique, incoming URLs that represent requests should be dispatched to handlers in the sub-application, and identified and dispatched to the application object of the sub-application (rather than a class in the "parent" application). You then define another dispatch tuple in the sub-application, so that requests passed down from the parent are sent to their proper handlers below.
In addition, the URL processing system provides a means of capturing any input parameters and passing those as arguments to the
POST() handler classes.
While the Templetor system uses Python (in fact, when rendered, a template is compiled into Python code), there are a few restrictions to ensure code safety. For example, you cannot use
exec, nor can you use some of Python's built-in functions like
getattr. This lessens the likelihood that an out-of-control template might inadvertently corrupt the file system.
Web.py's forms module generates and validates HTML forms. It provides all the basic HTML controls -- textbox, password text area, dropdown, and more. The library consists of two classes:
Input. The former produces the HTML for a form, while the latter manages user input. (In fact, the HTML controls mentioned above are subclasses of
Input.) You can attach validators to individual fields or issue a validation on the entire form. Validating the entire form allows you to compare multiple input fields in a form before allowing the form's input data to be passed into a database. So, for example, you might want to verify that two input fields match before committing the form data to your database.
The Web.py online documentation suits the framework's minimalist philosophy: It's straightforward, clear, uncluttered, and to the point. You find what you need. The website provides an API reference (which is simply a guide to the framework's classes and methods, with minimal explanation), a cookbook organized by topic area, and categorized code examples. The website also provides several fully functioning Web applications, ranging from the most fundamental skeletal application to a simple blog that shows how to work with a back-end database. You'll also find a tutorial, but at the time of this writing, the tutorial was still a work in progress, scattered with numerous "to do" entries.
Web.py's author maintains that the framework seeks just the right level of abstraction. This is apparent in both the database classes and HTTP request processing. Just as the database classes do not hide the fact that you are doing inserts, updates, deletes, and selects, so the request processing does not hide the fact that the application is responding to
PUT() operations. This simplicity makes Web.py easy to learn, since users don't have to be figuring out both the abstraction and the operations being abstracted away.
Read reviews of other Python Web frameworks: