web.py is a web framework for Python that is as simple as it is powerful. web.py is in the public domain; you can use it for whatever purpose with absolutely no restrictions.
Firstly, web.py commits are very sporadic, unlike other popular frameworks. It is being worked on as an active project, but don't expect new features to be rolled out swiftly. A good amount of the recent commits appear to be bugfixes, which is a good sign in any project.
With that out of the way, lets begin this review of web.py, the famous web framework that powers reddit.com, and a list of other known websites. The framework itself was built by someone from reddit.com, the text on their website doesn't describe if he is a founder of reddit.com or merely a developer who worked there.
The installation of web.py was really simple, just one pip command got me the latest version to play with locally. Eclipse was also able to see it and use code completion with no difficulty. There was no additional deps other than Python's standard libraries, which is what I come to expect from micro-frameworks. I first went and typed out their example into Eclipse to see if code completion was working as expected and to get used to it's coding syntax. Front and center, this framework isn't shy to say that it uses Classes and supports the RESTful web right out of the box. Running the example proved to have very response request times. I do notice some lag with other frameworks when using them through localhost. One minor issue I noticed, is that the development server binds to all interfaces and not just localhost on your machine. This may cause headaches for some security conscious users.
Web.py can either use a multi-file format of custom design, or a single file format. What I mean by custom design, is that with the URL matching, you can tell it which module to fetch a particular view from. This allows you to place and name these modules at will, and no set layout for naming scheme is forced on you.
An interesting concept in web.py is an Auto application, where it will generate the URL tree based on the classes you built, with optionally using a path variable in the class to change which path it maps to. Although, I don't see very large applications using this, since it may make maintaining the application at future dates a tad difficult. I say this, as now the URLs for the application are not centralized, making it hard to tell what goes where and how everything is connected together.
web.py supports mounting apps to various root directories on your website. This is similar to adding application modules in other frameworks. This also makes it possible to use reusable web.py apps. A twist to this, is to map applications based solely on the connecting domain name. Yes, this can allow a single Python process to host multiple applications. This should not be used to host multiple applications by separate users.
During development, I got a tad frustrated that autoreload wasn't working with my code, and that pressing Ctrl-C had a rather long delay before the application terminated correctly. Not very polished. An interesting touch is the error pages provided appear to be right from Django, it looks exactly like a Django exception traceback page, using during development.
web.py comes with support for Database connectivity out of the box, although the oddest thing is that the tutorial doesn't explain how to connect to an SQLite databasepopular during development, the tutorial only mentions MySQL and Postgres. If someone is following the tutorial, it is most likely that they are following it and testing code along the side. The worse thing a tutorial can do is not provide a method for a user to easily use it, not every local workstation is going to have a full fledged database engine installed. For those that don't want to rummage through their source code looking for which database connection to use, here is a list of all their supported databases:
Now we come to the template engine included with web.py. Of course you are free to use another engine like Jinja2, but lets take a moment to see what web.py has to offer in it's templates engine. It supports what you come to expect from template engines, variables, and functions. Something more controversial is the ability to use Python code directly in your templates. While web.py doesn't advertise itself as an MVC framework, it's still bad coding practice to code directly in your templates, both for security reasons and for code cleanliness. The developers do take template security seriously, since you are allowed to code Python directly in the template. Templates will disallow the following code from being run:
- Unsafe statements like import, exec etc.
- Accessing attributes starting with _
- Unsafe builtins like open, getattr, setattr etc.
Unfortunately this list is not very verbose and uses etc a little too much, so it's hard to say exactly what else is blocked besides what is explained. If you don't feel the need to code directly in your templates, consider using an alternate template engine. Using an alternate engine is fully supported in the web.contrib.template module. It's nice to see many micro-frameworks making it easy to use 3rd party template engines. Sadly however, Jinja2 is not available in this module, and will need to be integrated manually.
Forms can be loosely compared to how SQLAlchemy allows you to create tables. It is not class-based, but uses a constructor with a variable amount of parameters to describe the object. If you enjoy how table creation is in SQLAlchemy, then you will feel right at home with web.py's form creation API. I personally prefer sub-classing over the use of a constructor. Validating and rendering the form in a view can be loosely compared to how Django handles it.
To extend web.py, and perform some sort of action before each request, there is something called Application Processors. The example displays how one would add authentication to their website. It's more like the boilerplate for authentication, don't expect any actual checks against a backend here. A processor could be used to check the amount of visitors currently on a website, or increase the view count for specific pages. The framework also supports sessions, and this page explains the same code, but shows how to do authentication with a session, rather than a cookie.
Speaking about authentication, web.py comes with an openid module, although it is not documented too well, so you may need to dive into the source code to figure out how to use it. I made no attempts during this review process to use the openid module, so it may still be under heavy development.
There are some components not explained in the main documentation, and only explained partly in the API documents. The majority of this framework's documentation you are going to refer to will be either in the API docs, or in the source code itself.
When it comes time to deploying your web.py application, you can do so with either WSGI or other methods such as FastCGI. Oddly FastCGI is the recommended method, I figure because it is the easiest under Apache. I prefer WSGI these days on alternative servers.
This concludes the review for web.py, which I believe is a little too unpolished for everyday projects. If you do choose to go with web.py, take the cons listed below into heavy consideration. The lack of full documentation may be your first huge bottleneck, as it does have a large resource of tools at your disposal, much of these tools are not fully documented and explained.
- Class-based RESTful views
- Django-like traceback error pages
- Easy to use and understand Forms API
- Built-in Cookie and Session handling
- WSGI compliant
- Local development server defaults to 0.0.0.0
- Tutorial does not use SQLite
- Incomplete documentation
- No table creation DB API