wheezy web: introduction

The key of success for any medium to high complexity system is in separation of domain concerns. Given that choice in architectural design for web framework, the development activities are split by distinct, non-dependent parts. The wheezy.web is a lightweight WSGI web framework and serves a glue purpose between various other packages developed under wheezy.* umbrella in loosely coupled way, it combines things essential for web application developer (presentation slides are here):

• routing - simple extensible mapping between URL patterns (as plain simple strings, curly expressions or regular expressions) to a handler; the mapping can include other mappings and constructed dynamically; reverse path by name
• domain model update from request input; validation
• transparent validation errors integration in HTML widgets
• authentication/authorization
• i18n (gettext)
• middlewares, response transforms, cookies, etc
• content caching, HTTP cache policy and cache profiles + cache dependency
• functional testing
• template engine agnostic, however brings wheezy.template. It offers HTML widgets for various template engines to make your code more readable and consistent (via template preprocessing to generate an optimal markup for given template engine)
• integration with pycrypto, lxml, python-memcached and pylibmc; the wheezy.captcha library is based on PIL
• documentation per package, tutorial, examples, demo
• Python 2.4 - 3.3+ ready

Python Web Caching Benchmark

Content caching is the most effective type of cache. This way your web handler is not executed to determine a valid response to user, instead one returned from cache. Since the operation is that simple, it should be the maximum possible speed your `real world` application capable to provide. There are several use cases when content caching is applicable:

• Site: the site content is changed rarely. The best case scenario is nginx+wsgi caching facilities, see more here.
• Handler: the site content caching policy vary, there are only few handlers were content caching is applicable.
• Managed (semi-real time): the site is dynamic, it is not permissible to cache a given output unless there is a way to invalidate content since some data changed, e.g. item price, new message arrived, etc. Read more here or give it a try.

How python web frameworks respond to this challenge? Only few (per documentation on official web site):

1. django 1.4.2
2. flask 0.9
3. wheezy.web 0.1.307

Web content caching benchmark is provided for two types of caching: memory and distributed. The cached content size is 8890 bytes (with applied gzip transform the content size down to 1086 bytes).

Python Templates Benchmark

Python template engines offer high reusability of markup code and the following features are used by content developers most of the time:

• Includes: useful to incorporate some snippets of content that in most cases are common to the site, e.g. footer, scripts, styles, etc.
• Extends: useful to define a master layout for the majority of the site content with placeholders, e.g. sidebar, horizontal menu, content, etc. The content developers extend the master layout by substituting available placeholders.
• Widgets: usually small snippets of highly reusable markup, e.g. list item, button, etc. The content developers use widgets to increase readability and enforce consistency of design.

We will examine all mentioned features above. Test is executed in isolated environment using CPython 2.7. Latest available versions (April 2, 2015):

1. django 1.8
2. jinja2 2.7.3
3. mako 1.0.1
4. tenjin 1.1.1
5. tornado 4.1
6. wheezy.template 0.1.159

Includes & Extends: in this test case an initial version of HTML content is refactored to use include and extend features of respective template engine.

Widgets: the test case is around how widget is built and used.

02-single - a widget is built in a way that loop is inside; 03-loop - a widget represent an item that is rendered in a loop.

Python Web Frameworks PEP8 Consistency

The code is read much more often than it is written. The PEP8 guidelines are intended to improve the readability of code. Readability counts, no doubt, but readability consistency is important, it is equally important to know when to be inconsistent. The report below makes excuse for the following:

E501 line too long (> 79 characters)
E231 missing whitespace after ',:'
W291 trailing whitespace
W293 blank line contains whitespace

In this post we will take a look at web frameworks source code readability. The ratio between a web framework total python source lines to PEP8 errors found represents PEP8 error rate in respectful framework:

1. bottle
2. cherrypy
3. circuits
4. django
5. falcon
6. flask
7. pyramid
8. pysi
9. tornado
10. turbogears
11. web.py
12. web2py
13. webapp2
14. wheezy.web

The source code is hosted on bitbucket, let clone it into some directory and setup virtual environment (this will download source code per framework listed above).

hg clone https://bitbucket.org/akorn/helloworld
cd helloworld/04-pep8 && make env up

The make file has a target for each metric, so in order to gather pep8 count issue make pep8, or make count to count total lines.

Python Web Reverse URLs Benchmark

How fast python web frameworks reverse urls? While routing is a mapping of incoming request to a handler, url reverse function is designed to build urls for those handlers. A web page may have a number of urls from few dozen to hundreds... all related to your web site (e.g. links between related pages, tag cloud, most viewed posts, etc). A typical web application usually has deal with the following reverse url use cases:

• Static: the URL path is fixed and never changes, e.g. https://bitbucket.org/explore.
• Merge: the URL path is constructed dynamically, some information is taken from URL. A `user page` shows repositories. In this case a list of user repositories will be constructed as merge of information that came from URL (user name) and repository name.
• Route: the URL path is constructed dynamically, all information can be taken from URL. A `repository page` displays a number of features: downloads, source, etc. Those links include current route information (user name and repository name).

We will examine all reverse url use cases mentioned above with... a trivial 'Hello World!' application that builds 20 urls for each case. The benchmark is executed in isolated environment using CPython 2.7. Latest available versions (November 17, 2013):

1. django 1.6
2. flask 0.10.1
3. pylons 1.0.1
4. pyramid 1.5a2
5. tornado 3.1.1
6. wheezy.web 0.1.373

Let setup few prerequisites to be able run this in a clean debian testing installation.

apt-get install make python-dev python-virtualenv \
    mercurial unzip

The source code is hosted on bitbucket, let clone it into some directory and setup virtual environment (this will download all necessary package dependencies per framework listed above).

hg clone https://bitbucket.org/akorn/helloworld
cd helloworld/03-urls && make env

Once environment is ready we can run benchmarks:

env/bin/python benchmarks.py