email package, as well as the tkinter GUI toolkit. Both are fully sufficient for the utility
we’ve implemented here, but they might limit further progress.
For example, the current lack of an HTML viewer widget in the base tkinter toolkit
precludes HTML mail viewing and composition in the GUI itself. Moreover, although
PyMailGUI broadly supports Internationalization today, it must rely on workarounds
to get email to work at all. To be fair, some of the email package’s issues described in
this book will likely be fixed by the time you read about them, and email in general is
probably close to a worst case for Internationalization issues brought into the spotlight
by Unicode prominence in Python 3.X. Still, such tool constraints might impede further
system evolution.
On the other hand, despite any limitations in the tools it deploys, PyMailGUI does
achieve all its goals—it’s an arguably full-featured and remarkably quick desktop email
client, which works surprisingly well for my emails and preferences and performs ad-
mirably on the cases I’ve tested to date. It may not satisfy your tastes or constraints,
but it is open to customization and imitation. Suggested exercises and further tweaking
are therefore officially delegated to your imagination; this is Python, after all.
This concludes our tour of Python client-side protocols programming. In the next
chapter, we’ll hop the fence to the other side of the Internet world and explore scripts
that run on server machines. Such programs give rise to the grander notion of applica-
tions that live entirely on the Web and are launched by web browsers. As we take this
leap in structure, keep in mind that the tools we met in this and the previous chapter
are often sufficient to implement all the distributed processing that many applications
require, and they can work in harmony with scripts that run on a server. To completely
understand the Web world view, though, we need to explore the server realm, too.
1124 | Chapter 14: The PyMailGUI Client