The user input dialog on opens and saves is the only GUI implication of these policies;
other options are selected in configuration module assignments. Since it’s impossible
to predict all possible use case scenarios, PyEdit takes a liberal approach: it supports
all conceivable modes, and allows the way it obtains file encodings to be heavily tailored
by users in the package’s own textConfig module. It attempts one encoding name
source after another, if enabled in textConfig, until it finds an encoding that works.
This aims to provide maximum flexibility in the face of an uncertain Unicode world.
For example, subject to settings in the configuration file, saves reuse the encoding used
for the file when it was opened or initially saved, if known. Both new files begun from
scratch (with New or manual text inserts) and files opened in binary mode as a last
resort have no known encoding until saved, but files previously opened as text do. Also
subject to configuration file settings, we may prompt users for an encoding on Save As
(and possibly Save) because they may have a preference for new files they create. We
also may prompt when opening an existing file, because this requires its current en-
coding; although the user may not always know what this is (e.g., files fetched over the
Internet), the user may wish to provide it in others. Rather than choosing a course of
action in such cases, we rely on user configuration.
All of this is really relevant only to PyEdit clients that request an initial file load or allow
files to be opened and saved in the GUI. Because content can be inserted as str or
bytes, clients can always open and read input files themselves prior to creating a text
editor object and insert the text manually for viewing. Moreover, clients can fetch con-
tent manually and save in any fashion preferred. Such a manual approach might prove
useful if PyEdit’s polices are undesirable for a given context. Since the Text widget
always returns content as a str, the rest of this program is unaffected by the data type
of text inserted.
Keep in mind that these policies are still subject to the Unicode support and constraints
of the underlying Tk GUI toolkit, as well as Python’s tkinter interface to it. Although
PyEdit allows text to be loaded and saved in arbitrary Unicode encodings, it cannot
guarantee that the GUI library will display such text as you wish. That is, even if we
get the Unicode story right on the Python side of the fence, we’re still at the mercy of
other software layers which are beyond the scope of this book. Tk seems to be robust
across a wide range of character sets if we pass it already decoded Python str Unicode
strings (see the Internationalization support in Chapter 14’s PyMailGUI for samples),
but your mileage might vary.
Also keep in mind that the Unicode policies adopted in PyEdit
reflect the use cases of its sole current user, and have not been broadly tested for ergo-
nomics and generality; as a book example, this doesn’t enjoy the built-in test environ-
ment of open source projects. Other schemes and source orderings might work well,
too, and it’s impossible to guess the preferences of every user in every context. For
instance:
Unicode options and choices.
690 | Chapter 11: Complete GUI Programs