In release 2.2, Python introduced a new flavor of classes, known as new-style classes; classes following the original and traditional model became known as classic classes when compared to the new kind. In 3.X the class story has merged, but it remains split for Python 2.X users and code:
In Python 3.X, all classes are automatically what were formerly called “new style,” whether they explicitly inherit from object or not. Coding the object superclass is optional and implied.
In Python 2.X, classes must explicitly inherit from object (or another built-in type) to be considered “new style” and enable and obtain all new-style behavior. Classes without this are “classic.”
Because all classes are automatically new-style in 3.X, the features of new-style classes are simply normal class features in that line. I’ve opted to keep their descriptions in this section separate, however, in deference to users of Python 2.X code—classes in such code acquire new-style features and behavior only when they are derived from object.
In other words, when Python 3.X users see descriptions of “new style” topics in this book, they should take them to be descriptions of existing properties of their classes. For 2.X readers, these are a set of optional changes and extensions that you may choose to enable or not, unless the code you must use already employs them.
In Python 2.X, the identifying syntactic difference for new-style classes is that they are derived from either a built-in type, such as list, or a special built-in class known as object. The built-in name object is provided to serve as a superclass for new-style classes if no other built-in type is appropriate to use:
class newstyle(object): # 2.X explicit new-style derivation
...normal class code... # Not required in 3.X: automatic
Any class derived from object, or any other built-in type, is automatically treated as a new-style class. That is, as long as a built-in type is somewhere in its superclass tree, a 2.X class acquires new-style class behavior and extensions. Classes not derived from built-ins such as object are considered classic.
As we’ll see, new-style classes come with profound differences that impact programs broadly, especially when code leverages their added advanced features. In fact, at least in terms of its OOP support, these changes on some levels transform Python into a different language altogether—one that’s mandated in the 3.X line, one that’s optional in 2.X only if ignored by every programmer, and one that borrows much more from (and is often as complex as) other languages in this domain.
New-style classes stem in part from an attempt to merge the notion of class with that of type around the time of Python 2.2, though they went unnoticed by many until they were escalated to required knowledge in 3.X. You’ll need to judge the success of that merging for yourself, but as we’ll see, there are still distinctions in the model—now between class and metaclass—and one of its side effects is to make normal classes more powerful but also substantially more complex. The new-style inheritance algorithm formalized in Chapter 40, for example, grows in complexity by at least a factor of 2.
Still, some programmers using straightforward application code may notice only slight divergence from traditional “classic” classes. After all, we’ve managed to get to this point in this book writing substantial class examples, with mostly just passing mentions of this change. Moreover, the classic class model still available in 2.X works exactly as it has for some two decades.[63]
However, because they modify core class behaviors, new-style classes had to be introduced in Python 2.X as a distinct tool so as to avoid impacting any existing code that depends on the prior model. For example, some subtle differences, such as diamond pattern inheritance search and the interaction of built-in operations and managed attribute methods such as __getattr__ can cause some existing code to fail if left unchanged. Using optional extensions in the new model such as slots can have the same effect.
The class model split is removed in Python 3.X, which mandates new-style classes, but it still exists for readers using 2.X, or reusing the vast amount of existing 2.X code in production use. Because this has been an optional extension in 2.X, code written for that line may use either class model.
The next two top-level sections provide overviews of the ways in which new-style classes differ and the new tools they provide. These topics represent potential changes to some Python 2.X readers, but simply additional advanced class topics to many Python 3.X readers. If you’re in the latter group, you’ll find full coverage here, though some of it is presented in the context of changes—which you can accept as features, but only if you never must deal with any of the millions of lines of existing 2.X code.
[63] As a data point, the book Programming Python, a 1,600-page applications programming follow-up to this book that uses 3.X exclusively, neither uses nor needs to accommodate any of the new-style class tools of this chapter, and still manages to build significant programs for GUIs, websites, systems programming, databases, and text. It’s mostly straightforward code that leverages built-in types and libraries to do its work, not obscure and esoteric OOP extensions. When it does use classes, they are relatively simple, providing structure and code factoring. That book’s code is also probably more representative of real-world programming than some in this language tutorial text—which suggests that many of Python’s advanced OOP tools may be artificial, having more to do with language design than practical program goals. Then again, that book has the luxury of restricting its toolset to such code; as soon as your coworker finds a way to use an arcane language feature, all bets are off!