Unicode limitations here stem from the limitations of the email package in
Python 3.1 upon which PyMailGUI heavily depends. It may be difficult for Python-
coded email clients to support some features better until Python’s libraries do, too.
Moreover, the Unicode support that is present in this program has been tested
neither widely nor rigorously. Just like Chapter 11’s PyEdit, this is currently still a
single-user system designed to work as a book example, not an open source project.
Because of that, some of the current Unicode policies are partially heuristic in
nature and may have to be honed with time and practice.
For example, it may prove better in the end to use UTF-8 encoding (or none at all)
for sends in general, instead of supporting some of the many user options which
are included in this book for illustration purposes. Since UTF-8 can represent most
Unicode code points, it’s broadly applicable.
More subtly, we might also consider propagating the main text part’s Unicode
encoding to the embedded PyEdit component in view and edit windows, so it can
be used as a known encoding by the PyEdit Save button. As is, users can pop up
the main text’s part in view windows to save with a known encoding automatically,
but saves of drafts for mails being edited fall back on PyEdit’s own Unicode policies
and GUI prompts. The ambiguous encoding for saved drafts may be unavoidable,
though—users might enter characters from any character set, both while writing
new mails from scratch and while editing the text of replies and forwards (just like
headers in replies and forwards, the initial known encoding of the original main
text part may no longer apply after arbitrary edits).
In addition, there is no support for non-ASCII encodings of full mail text, it’s not
impossible that i18n encoded text might appear in other contexts in rare emails
(e.g., in attachment filenames, whose undecoded form may or may not be valid on
the receiving platform’s filesystem, and may require renaming if allowed at all),
and although Internationalization is supported for mail content, the GUI itself still
uses English for its buttons, labels, and titles—something that a truly location-
neutral program may wish to address.
In other words, if this program were to ever take the leap to commercial-grade or
broadly used software, its Unicode story would probably have to be revisited. Also
discussed in Chapter 13, a future release of the email package may solve some
Unicode issues automatically, though PyMailGUI may also require updates for the
solutions, as well as for incompatibilities introduced by them. For now, this will
have to stand as a useful object lesson in itself: for both better and worse, such
changes will always be a fact of life in the constantly evolving world of software
development.And so on—because this software is open source, it is also necessarily open-ended.
Ultimately, writing a complete email client is a substantial undertaking, and we’ve
taken this example as far as we can in this book. To move PyMailGUI further along,
we’d probably have to consider the suitability of both the underlying Python 3.1
Ideas for Improvement| 1123