RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


The Python 2.5 Goodie Bag: Language Enhancements and Modules : Page 4

The 2.5 version of Python offered lots of useful enhancements. In this article, you'll learn about some specific modules, as well as performance improvements, that are likely to bring big smiles to the faces of many Python developers.

More Modules

Hashlib is a new module that provides various secure hash algorithms. The supported algorithms (always available) are: MD5, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. Other algorithms may be present and you can try to instantiate them. Secure hash algorithms are used for protocols and standards such as SSH, SSL, PGP, TLS, and S/MIME.

Hashlib has a uniform simple interface for all the algorithms and it's very easy to use. You create a hash object. You call the update() method one or more times to add text. Finally you call the digest() or hexdigest() methods to get the hash value.

import hashlib
x = hashlib.sha256()
x.update('Yeah, ')
x.update('it ')
d1 = x.digest()
print x.hexdigest()

x = hashlib.sha256()
x.update('Yeah, it works!!!')
d2 = x.digest()
print x.hexdigest()
assert d1 == d2

x = hashlib.sha224()
x.update('Yeah, it works!!!')
print x.hexdigest()

x = hashlib.sha1()
x.update('Yeah, it works!!!')
print x.hexdigest()

x = hashlib.md5()
x.update('Yeah, it works!!!')
print x.hexdigest()

You can call the update() method with one big string or multiple times with consecutive sub-strings. If the sub-strings add up to the big string you will get the same hash value (from the same algorithm). The hash values differ in the number of bits they return: md5 returns 128 bits, sha-1 returns 160 bits, and the sha-xxx algorithms return xxx bits respectively.

The digest() method returns a raw buffer of bytes that might contain non-printable characters, so I just used the result for comparison. The hexdigest() method returns a stringified hexadecimal representation of the digest value that you may safely print.

If OpenSSL is installed hashlib will bind to it dynamically, and then additional algorithms may be available. You need to use the new() method to access additional algorithms, if present, and pass the algorithm name to new.

Hashlib deprecates the md5 and sha1 modules. These modules were available in earlier versions, and the new hashlib borrows their simple interface. The modules are still available as a backward compatibility gesture, but they actually use hashlib under the covers.

WSGI stands for the Web Server Gateway Interface. It is a standard interface for web servers, web applications, and middleware. The idea is that web applications that comply with WSGI will able to utilize lots of WSGI-compliant middleware components (e.g. authentication, session, compression) and deploy to any WSGI-compliant web server. The WSGI specification is not aimed at the web application developer, but at the web framework developer.

Some history ... Python has an enormous number of web frameworks. The (speculative) reason is that it is so easy to write a web framework in Python that people preferred to roll their own than to use an existing one. Existing frameworks were often incomplete, not well documented, and targeted at the specific needs of some other developer. There is an ongoing debate in the community whether this proliferation is beneficial.

In the last year, this debate grew more intense as Ruby on Rails blazed new trails and the Python community got nervous. By comparison to Rails, Python's babel tower of web frameworks looked like a bad idea. There were various proposals to unify web frameworks or to pick one web framework.

In the end, two web frameworks emerged as de facto leaders: DJango and TurboGears. (It is debatable whether these are really the leading Python web frameworks, but they are definitely the only two with a book.)

Editor's Note: The author is a co-author of the TurboGears book, but he does not earn royalties.

Back to WSGI, the fragmentation of the Python web framework scene worried a few people including Philip J. Eby. Eby, a serious mover and shaker in the Python community, is known for his PEAK initiative, which was supposed to provide a pythonic J2EE. Somewhere along the way PEAK started to split and spin off important standalone projects and other ideas such as generic functions and setuptools. Eby decided to do something about the web framework situation and wrote Python Enhancement Proposal (PEP)-333, "Python Web Server Gateway Interface" v1.0 and followed up with a reference implementation called (you guessed it) wsgiref.

The core of wsgiref is so simple that you can write a fully functioning web application in a few lines of code (I'll provide it soon) that you can effortlessly deploy on any WSGI-compliant server with any WSGI middleware. Before I start showcasing wsgiref, I want to stress that you SHOULD NOT develop web applications from scratch. It is very simple and possible, but there is no need. There are lots of excellent Python web frameworks out there and they all support WSGI, so go ahead and use them for real projects.

Now I'll get down to writing some code. A WSGI web application is callable (i.e. a function, a class constructor, or any object with a __call__ method). That's it. You pass this callable to a WSGI-compliant server and that's your deployment. WSGI is based on HTTP's request-response model. Whenever a request comes in the server will recognize your application as callable and pass two arguments: the environment and the start_response callable. In your code you can query the environment that contains the request's path (URL), the HTTP headers' query parameters, and other relevant data. You call the start_response callable and pass the response headers and status; then you return the response body as a list of strings. It's really simple.

I'm a very creative guy, so when I thought about a cool web application a "Quote of the Day" immediately jumped to mind. I carefully Googled it to make sure no one thought about it before me, and I was immediately rewarded with 134,000,000 results :-). Being strong-willed I decided to keep going with the original plan. My QOTD web application is highly sophisticated and chockfull of buzzwords. It has a dynamic back-end web service that aggregates an RSS feed from another web application (http://brainyquote.com), parses the RSS using ElementTree, extracts the quotes of the day, and stores the quotes in a lightning fast in-memory database (a simple Python list). When a request comes in the QOTD web application selects a random quote, formats it in the following format: <Famous Person> once said... <Quote> and returns it to the caller. The full code consists of 10 lines of code + three lines of import statements.

I start by importing all the necessary modules. The quotes list is initialized to the empty list. The qotd_app function is the actual web application callable (yes, three lines of code). It gets a random quote from the quotes "database" (the quotes list will already be populated by the time qotd_app is called for the first time). It calls start_response with the ok status and a content type HTTP header of text/html. Finally, it returns the body of the response, which is the quote itself wrapped in a minimal HTML markup.

The code after the function definition is the main initialization code. It downloads the QOTD RSS feed using urllib2.urlopen. It proceeds to parse it using ElementTree.XML and finds all the elements in the feed called <item>. The relevant information in each item is the famous person and her/his quote text. These are the <title> and <description> sub-elements of <item>. It formats the quote into the 'once said...' format and appends it to the quotes list. The next thing is to start the WSGI-compliant server and pass it the qotd_app function. The server will listen on port 8888.

To test it save the code to a Python file and run it, then browse with your favorite browser to http://localhost:8888 and check out the pearls of wisdom it will emit. Every refresh will bring a new random quote from the list. The code is shown in Listing 1.

WSGI web applications are cool but not really useful in professional applications. Besides WSGI web applications there are two other pieces to WSGI: web servers and middleware. You probably don't want to write a new web server, but if you are serious about WSGI you'd do well to investigate the WSGI middleware path. These are components that sit between the web application and web server. You can compose them freely and, because they all expose the same callable API, you can wrap any web application with multiple WSGI middleware.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date