parsed and unparsed content. These interfaces, along with some user-interface magic,
will lead us to full-blown email clients and websites in later chapters.
Two design notes worth mentioning up front: First, none of the code in this package
knows anything about the user interface it will be used in (console, GUI, web, or other)
or does anything about things like threads; it is just a toolkit. As we’ll see, its clients
are responsible for deciding how it will be deployed. By focusing on just email pro-
cessing here, we simplify the code, as well as the programs that will use it.
Second, each of the main modules in this package illustrate Unicode issues that con-
front Python 3.X code, especially when using the 3.1 Python email package:
- The sender must address encodings for the main message text, attachment input
files, saved-mail output files, and message headers. - The fetcher must resolve full mail text encodings when new mails are fetched.
- The parser must deal with encodings in text part payloads of parsed messages, as
well as those in message headers.
In addition, the sender must provide workarounds for the binary parts generation and
text part creation issues in email described earlier in this chapter. Since these highlight
Unicode factors in general, and might not be solved as broadly as they might be due to
limitations of the current Python email package, I’ll elaborate on each of these choices
along the way.
The next few sections list mailtools source code. Together, its files consist of roughly
1,050 lines of code, including whitespace and comments. We won’t cover all of this
package’s code in depth—study its listings for more details, and see its self-test module
for a usage example. Also, for more context and examples, watch for the three clients
that will use this package—the modified pymail2.py following this listing, the
PyMailGUI client in Chapter 14, and the PyMailCGI server in Chapter 16. By sharing
and reusing this module, all three systems inherit all its utility, as well as any future
enhancements.
Initialization File
The module in Example 13-21 implements the initialization logic of the mailtools
package; as usual, its code is run automatically the first time a script imports through
the package’s directory. Notice how this file collects the contents of all the nested
modules into the directory’s namespace with from * statements—because mailtools
began life as a single .py file, this provides backward compatibility for existing clients.
We also must use package-relative import syntax here (from .module), because Python
3.X no longer includes the package’s own directory on the module import search path
(only the package’s container is on the path). Since this is the root module, global
comments appear here as well.
The mailtools Utility Package | 957