Although the Python 3.X line covered in the two most recent editions of this book is largely the same language as its 2.X predecessor, it differs in some crucial ways. As discussed in the preface and summarized in the preceding section, 3.X’s nonoptional Unicode model, mandatory new-style classes, and broader emphasis on generators and other functional tools alone can make it a materially different experience.
On the whole, Python 3.X may be a cleaner language, but it is also in many ways a more sophisticated language, relying upon concepts that are substantially more advanced. In fact, some of its changes seem to assume you must already know Python in order to learn Python. The preface mentioned some of the more prominent circular knowledge dependencies in 3.X that imply forward topic dependencies.
As a random example, the rationale for wrapping dictionary views in a list call in 3.X is incredibly subtle and requires substantial foreknowledge—of views, generators, and the iteration protocol, at the least. Keyword arguments are similarly required in simple tools (e.g., printing, string formatting, dictionary creation, and sorting) that crop up long before a newcomer learns enough about functions to understand them fully. One of this book’s goals is to help bridge this knowledge gap in today’s 2.X/3.X dual-version world.
There are additional changes in Python 3.X not listed in this appendix, simply because they don’t affect this book. For example, some standard libraries and development tools are outside this book’s core language scope, though some are mentioned along the way (e.g., timeit), and others have always been covered here (e.g., PyDoc).
For completeness, the following sections note 3.X developments in these categories. Some of the changes in these categories are also listed later in this appendix, in conjunction with the book edition and Python version in which they were introduced.
Formally speaking, the Python standard library is not a part of this book’s core language subject, even though it’s always available with Python, and permeates realistic Python programs. In fact, the libraries were not subject to the temporary 3.X language changes moratorium enacted during 3.2’s development.
Because of this, changes in the standard library have a larger impact on applications-focused books like Programming Python than they do here. Although most standard library functionality is still present, Python 3.X takes further liberties with renaming modules, grouping them into packages, and changing API call patterns.
Some library changes are much broader, though. Python 3.X’s Unicode model, for example, creates widespread differences in 3.X’s standard library—it potentially impacts any program that processes file content, filenames, directory walkers, pipes, descriptor files, sockets, text in GUIs, Internet protocols such as FTP and email, CGI scripts, web content of many kinds, and even some persistence tools such as DBM files, shelves, and pickles.
For a more comprehensive list of changes in 3.X’s standard libraries, see the “What’s New” documents for 3.X releases (especially 3.0) in Python’s standard manual set. Because it uses Python 3.X throughout, the aforementioned Programming Python can also serve as a guide to 3.X library changes.
Though most development tools are the same between 2.X and 3.X (e.g., for debugging, profiling, timing, and testing), a few have undergone changes in 3.X along with the language and library. Among these, the PyDoc module documentation system has moved away from its former GUI client model in 3.2 and earlier, replacing it with an all web browser interface.
Other noteworthy changes in this category: the distutils package, used to distribute and install third-party software, is to be subsumed by a new packaging system in 3.X; the new __pycache__ byte code storage scheme described in this book, though an improvement, potentially impacts many Python tools and programs; and the internal implementation of threading changed as of 3.2 to reduce contention by modifying the global interpreter lock (GIL) to use absolute time slices instead of a virtual machine instruction counter.
If you are migrating from Python 2.X to Python 3.X, be sure to also see the 2to3 automatic code conversion script that is shipped with Python 3.X. It’s currently available in Python’s Tools\Scripts install folder, or via a web search. This script cannot translate everything, and attempts to translate core language code primarily—3.X standard library APIs may differ further. Still, it does a reasonable job of converting much 2.X code to run under 3.X.
Conversely, the 3to2 back-conversion program, currently available in the third-party domain, can also translate much Python 3.X code to run in 2.X environments. Depending on your goals and constraints, either 2to3 or 3to2 may prove useful if you must maintain code for both Python lines; see the Web for details, and additional tools and techniques.
It’s also possible to write code that runs portably on both 2.X and 3.X using techniques presented in this book—importing 3.X features from __future__, avoiding version-specific tools, and so on. Many of the examples in this book are platform-neutral. For examples, see the benchmarking tools in Chapter 21, the module reloaders and comma formatter in Chapter 25, the class tree listers in Chapter 31, most of the larger decorator examples in Chapter 38 and Chapter 39, the joke script at the end of Chapter 41, and more. As long as you understand 2.X/3.X core language differences, coding around them is often straightforward.
If you’re interested in writing code for both 2.X and 3.X, see also six—a library of cross-version mapping and renaming tools, which currently lives at http://packages.python.org/six. Naturally, this package can’t offset every difference in language semantics and library APIs, and in many cases you must use its library tools instead of straight Python to realize its portability gains. In exchange, though, your programs become much more version-neutral when using this library’s tools.