Chapter 11 ■ the World Wide Web211• Pyramid: A remarkable and high-performance synthesis of the lessons learned by community
members in the old Zope and Pylons communities and the go-to framework for developers
working in fluid URL spaces like those created when you author a content management system
(CMS) that lets users create subfolders and additional web pages through a mere click of
their mouse. While it can support predefined URL structures as well as any of the previous
frameworks, it can go further by supporting object traversal where the framework itself
understands that your URL components are naming containers, content, and views that the
URL is visiting, in the same way that a filesystem path visits directories before arriving at a file.You might be tempted to choose a web framework by its reputation—based perhaps on the previous paragraphs,
plus a close read of their web sites and what you see on social media sites or Stack Overflow.
But I will suggest an even more important direction: if you have co-workers or friends at your local Python
meetup who are already partisans of a framework and can offer you regular help through e-mail or IRC, you might
want to choose that framework over a comparable one whose web site or feature list you like a little more. Having
the live help of someone who has already been through the typical error messages and misunderstandings can often
trump whether a particular feature of the framework is slightly more or less difficult to use.
WebSockets
Web sites powered by JavaScript often want to support live updates of their content. If someone tweets, then Twitter
wants to update the page you are looking at without the expense of the browser polling every second to ask whether
anything new has appeared. The Websocket Protocol (RFC 6455) is the most powerful and turbocharged of the
possible solutions to this “long polling problem.”
Earlier work-arounds were possible, like the famous genre of Comet techniques. One Comet technique is for the
client to make an HTTP request to a path; in response, the server hangs, leaving the socket open, and waits to respond
until an actual event (such as a new incoming tweet) finally happens and can be delivered in the response.
Because WSGI supports only traditional HTTP, you will have to move outside the realm of both standard web
frameworks and the full slate of WSGI-compatible web servers such as Gunicorn, Apache, and nginx in order to
support WebSockets.
The fact that WSGI cannot do WebSockets is one major reason for the popularity of the stand-alone Tornado
server-framework.
Whereas HTTP operates lockstep where the client speaks first with a single request and then waits for the server
to complete its response before following up with another request, a socket that has switched into WebSockets mode
supports messages traveling in either direction at any moment without waiting for each other. The client can send
live updates to the server as the user moves around the screen interacting with the web page, while the server is
simultaneously sending down updates that are arriving from other sources.
On the wire, a WebSocket conversation starts with what looks like an HTTP request and response but which, in
their headers and status code, are negotiating a switch away from HTTP on the socket. Once the switch is complete,
a new system of framing data takes over that is detailed in the RFC.
WebSocket programming typically involves heavy coordination between a front-end JavaScript library and the
code running on the server, which is not covered in this book. A simple starting point would be the documentation
for the tornado.websocket module, which includes a snippet of Python and JavaScript code that can talk to each
other through a pair of symmetric callbacks. Check out any good reference on asynchronous front-end browser
programming for ideas on how you can use such a mechanism to power live updates to web pages.