Learning Python - Mark Lutz [337]
I2.w
Right away, this code invokes inheritance. Because this is an object.attribute expression, it triggers a search of the tree in Figure 25-1—Python will search for the attribute w by looking in I2 and above. Specifically, it will search the linked objects in this order:
I2, C1, C2, C3
and stop at the first attached w it finds (or raise an error if w isn’t found at all). In this case, w won’t be found until C3 is searched because it appears only in that object. In other words, I2.w resolves to C3.w by virtue of the automatic search. In OOP terminology, I2 “inherits” the attribute w from C3.
Ultimately, the two instances inherit four attributes from their classes: w, x, y, and z. Other attribute references will wind up following different paths in the tree. For example:
I1.x and I2.x both find x in C1 and stop because C1 is lower than C2.
I1.y and I2.y both find y in C1 because that’s the only place y appears.
I1.z and I2.z both find z in C2 because C2 is further to the left than C3.
I2.name finds name in I2 without climbing the tree at all.
Trace these searches through the tree in Figure 25-1 to get a feel for how inheritance searches work in Python.
The first item in the preceding list is perhaps the most important to notice—because C1 redefines the attribute x lower in the tree, it effectively replaces the version above it in C2. As you’ll see in a moment, such redefinitions are at the heart of software customization in OOP—by redefining and replacing the attribute, C1 effectively customizes what it inherits from its superclasses.
Classes and Instances
Although they are technically two separate object types in the Python model, the classes and instances we put in these trees are almost identical—each type’s main purpose is to serve as another kind of namespace—a package of variables, and a place where we can attach attributes. If classes and instances therefore sound like modules, they should; however, the objects in class trees also have automatically searched links to other namespace objects, and classes correspond to statements, not entire files.
The primary difference between classes and instances is that classes are a kind of factory for generating instances. For example, in a realistic application, we might have an Employee class that defines what it means to be an employee; from that class, we generate actual Employee instances. This is another difference between classes and modules: we only ever have one instance of a given module in memory (that’s why we have to reload a module to get its new code), but with classes, we can make as many instances as we need.
Operationally, classes will usually have functions attached to them (e.g., computeSalary), and the instances will have more basic data items used by the class’ functions (e.g., hoursWorked). In fact, the object-oriented model is not that different from the classic data-processing model of programs plus records; in OOP, instances are like records with “data,” and classes are the “programs” for processing those records. In OOP, though, we also have the notion of an inheritance hierarchy, which supports software customization better than earlier models.
Class Method Calls
In the prior section, we saw how the attribute reference I2.w in our example class tree was translated to C3.w by the inheritance search procedure in Python. Perhaps just as important to understand as the inheritance of attributes, though, is what happens when we try to call methods (i.e., functions attached to classes as attributes).
If this I2.w reference is a function call, what it really means is “call the C3.w function to process I2.” That is, Python will automatically map the call I2.w() into the call C3.w(I2), passing in the instance as the first argument to the inherited function.
In fact, whenever we call a function attached to a class in this fashion, an instance of the class is always implied. This implied subject or context is part of the reason we refer to this as an object-oriented model—there is always a subject object when