The Email Package: Past, Present, and Future

Audience level:
Core Python (Language, Stdlib)
March 10th 4:15 p.m. – 4:55 p.m.


The email package in the Python Standard library has had a somewhat rocky transition into the Python3 era, and still doesn't handle non-ASCII easily. That is about to change. This talk will compare how things worked in Python2 (the past), how things work now (in Python3.2), and how things will work much better in the future (hopefully Python3.3).


The email package in Python2 was given the internal version number '4'. The email package in Python3 bumped that to '5'. We're now working on version '6', hoping that it will be in shippable state for the Python 3.3 release.

An email message, to the user, consists of a few headers (from, to, subject, date), some text (possibly rich-formatted html), and possibly some attachments. An email message sent over the Internet is a sequence of bytes formatted according to a very complex set of rules designed to make accurate interchange possible and backward compatibility with older software likely.

The email package tries to bridge the gap between the ideal user representation and the network format.

In the past, it has pretty much settled for providing basic tools that an application can use to do the translation itself. Using those tools to do anything non-trivial (such as using non-ASCII characters!) required understanding far more about the relevant email RFCs than any application developer should have to deal with. Now that Python3 makes working with unicode a fundamental, easy to use part of the language, it makes sense to have the email package provide an easy to use way of manipulating non-ASCII text in email messages. This talk will compare the old way of doing things with the new way. In doing so it will provide an introduction to the new capabilities of the email package, as well as providing a brief tutorial on how these facilities can be used to create, manipulate, receive, and transmit complex email messages.