determining if adding a “Re:” or “Fwd:” to the subject would be redundant; mail
list window width and height may now be configured in mailconfig; duplicates are
removed from the recipient address list in mailtools on sends to avoid sending
anyone multiple copies of the same mail (e.g., if an address appears in both To and
Cc); and other minor improvements which I won’t cover here. Look for “3.0” and
“4E” in program comments here and in the underlying mailtools package of
Chapter 13 to see other specific code changes.Unicode (Internationalization) support
I’ve saved the most significant PyMailGUI 3.0 upgrade for last: it now supports
Unicode encoding of fetched, saved, and sent mails, to the extent allowed by the
Python 3.1 email package. Both text parts of messages and message headers are
decoded when displayed and encoded when sent. Since this is too large a change
to explain in this format, the next section elaborates.
Version 3.0 Unicode support policies
The last item on the preceding list is probably the most substantial. Per Chapter 13, a
user-configurable setting in the mailconfig module is used on a session-wide basis to
decode full message bytes into Unicode strings when fetched, and to encode and decode
mail messages stored in text-mode save files.
More visibly, when composing, the main text and attached text parts of composed mails
may be given explicit Unicode encodings in mailconfig or via user input; when viewing,
message header information of parsed emails is used to determine the Unicode types
of both the main mail text as well as text parts opened on demand. In addition, Inter-
nationalized mail headers (e.g., Subject, To, and From) are decoded per email, MIME,
and Unicode standards when displayed according to their own content, and are auto-
matically encoded if non-ASCII when sent.
Other Unicode policies (and fixes) of Chapter 13’s mailtools package are inherited
here, too; see the prior chapter for more details. In summation, here is how all these
policies play out in terms of user interfaces:
Fetched emails
When fetching mails, a session-wide user setting is used to decode full message
bytes to Unicode strings, as required by Python’s current email parser; if this fails,
a handful of guesses are applied. Most mail text will likely be 7 or 8 bit in nature,
since original email standards required ASCII.
Composed text parts
When sending new mails, user settings are used to determine Unicode type for the
main text part and any text attachment parts. If these are not set in mailconfig, the
user will instead be asked for encoding names in the GUI for each text part. These
are ultimately used to add character set headers, and to invoke MIME encoding.
In all cases, the program falls back on UTF-8 if the user’s encoding setting or input
does not work for the text being sent—for instance, if the user has chosen ASCII
Major PyMailGUI Changes| 1017