Although I use PyMailGUI on a regular basis as is, there is always room for improvement to software, and this system is no exception. If you wish to experiment with its code, here are a few suggested projects:
Mail list windows could be sorted by columns on demand. This may require a more sophisticated list window structure.
The implementation of save-mail files limits their size by loading them into memory all at once; a DBM keyed-access implementation may work around this constraint. See the list windows module comments for ideas.
Hyperlink URLs within messages could be highlighted visually and made to spawn a web browser automatically when clicked by using the launcher tools we met in the GUI and system parts of this book (Tkinter’s text widget supports links directly).
Because Internet newsgroup posts are similar in structure to emails (header lines plus body text; see thenntplib example in Chapter 14), this script could in principle be extended to display both email messages and news articles. Classifying such a mutation as clever generalization or diabolical hack is left as an exercise in itself.
The help text has grown large in this version: this might be better implemented as HTML, and displayed in a web browser, with simple text as a fallback option. In fact, we might extract the simple text from the HTML, to avoid redundant copies.
Saves and Split writes could also be threaded for worst-case scenarios. For pointers on making Saves parallel, see the comments in the file class ofListWindows.py; there may be some subtle issues that require both thread locks and general file locking for potentially concurrent updates.
There is currently no way to delete an attachment once it has been added in compose windows. This might be supported by adding quick-access part buttons to compose windows, too, which could verify and delete the part when clicked.
We could add an automatic spam filter for mails fetched, in addition to any provided at the email server or ISP.
Mail text is editable in message view windows, even though a new mail is not being composed. This is deliberate—users can annotate the message’s text and save it in a text file with the Save button at the bottom of the window. This might be confusing, though, and is redundant (we can also edit and save by clicking on the main text’s quick-access part button). Removing edit tools would require extending PyEdit.
We could also add support for mail lists, allowing users to associate multiple email addresses with a saved list name. On sends to a list name, the mail would be sent to all on the list (the “To:” addresses passed tosmtplib), but the email list could be used for the email’s “To:” header line).
And so on—because this software is open source, it is also necessarily open-ended. Suggested exercises in this category are delegated to your imagination.
This concludes our tour of Python client-side 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 applications 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.
* And remember: you would have to multiply these line counts by a factor of four or five to get the equivalent in a language like C or C++. If you’ve done much programming, you probably recognize that the fact that we can implement a fairly full-featured mail processing program in roughly 2,000 lines of code speaks volumes about the power of the Python language and its libraries. For comparison, the original version of this program from the second edition of this book was just 725 lines in 3 new modules, but also was very limited—it did not support PyMailGUI2’s attachments, thread overlap, local mail files, and so on.
* In fact, my ISP’s webmail send system went down the very day I had to submit this edition of the book to my publisher! No worries—-I fired up PyMailGUI and used it to send the book as attachment files through a different server. In a sense, this book submitted itself.
* The standard library’s webbrowser module would help for HTML-based help. Actually, the help display started life even less fancy: it originally displayed help text in a standard information box pop up, generated by the Tkinter showinfo call used earlier in the book. This worked fine on Windows (at least with a small amount of help text), but it failed on Linux because of a default line-length limit in information pop-up boxes; lines were broken so badly as to be illegible.
Python 
