Remember those set functions we wrote in Part IV? Here’s what they look like brought back to life as a Python class. The following example (the file setwrapper.py) implements a new set object type by moving some of the set functions to methods, and adding some basic operator overloading. For the most part, this class just wraps a Python list with extra set operations. Because it’s a class, it also supports multiple instances and customization by inheritance in subclasses:

class Set:
   def _  _init_  _(self, value = []):      # Constructor
       self.data = []                 # Manages a list
       self.concat(value)

   def intersect(self, other):        # other is any sequence
       res = []                       # self is the subject
       for x in self.data:
           if x in other:             # Pick common items
               res.append(x)
       return Set(res)                # Return a new Set

   def union(self, other):            # other is any sequence
       res = self.data[:]             # Copy of my list
       for x in other:                # Add items in other
           if not x in res:
               res.append(x)
       return Set(res)

   def concat(self, value):           # value: list, Set...
       for x in value:                # Removes duplicates
          if not x in self.data:
               self.data.append(x)

   def _  _len_  _(self):          return len(self.data)        # len(self)
   def _  _getitem_  _(self, key): return self.data[key]        # self[i]
   def _  _and_  _(self, other):   return self.intersect(other) # self & other
   def _  _or_  _(self, other):    return self.union(other)     # self | other
   def _  _repr_  _(self):         return 'Set:' + 'self.data'  # Print

Overloading indexing enables instances of our Set class to masquerade as real lists. Because you will interact with and extend this class in an exercise at the end of this chapter, I won’t say much more about this code until Appendix B.

Beginning with Python 2.2, all the built-in types can now be subclassed directly. Type-conversion functions such as list, str, dict, and tuple have become built-in type names—although transparent to your script, a type-conversion call (e.g., list('spam')) is now really an invocation of a type’s object constructor.

This change allows you to customize or extend the behavior of built-in types with user-defined class statements: simply subclass the new type names to customize them. Instances of your type subclasses can be used anywhere that the original built-in type can appear. For example, suppose you have trouble getting used to the fact that Python list offsets begin at 0 instead of 1. Not to worry—you can always code your own subclass that customizes this core behavior of lists. The file typesubclass.py shows how:

# Subclass built-in list type/class.
# Map 1..N to 0..N-1; call back to built-in version.

class MyList(list):
    def _  _getitem_  _(self, offset):
        print '(indexing %s at %s)' % (self, offset)
        return list._  _getitem_  _(self, offset - 1)

if __name__ == '_  _main_  _':
    print list('abc')
    x = MyList('abc')               # _  _init_  _ inherited from list
    print x                         # _  _repr_  _ inherited from list

    print x[1]                      # MyList._  _getitem_  _
    print x[3]                      # Customizes list superclass method

    x.append('spam'), print x       # Attributes from list superclass
    x.reverse(  );      print x

In this file, the MyList subclass extends the built-in list’s _ _getitem_ _ indexing method only to map indexes 1 to N back to the required 0 to N−1. All it really does is decrement the index submitted, and call back to the superclass’ version of indexing, but it’s enough to do the trick:

% python typesubclass.py
['a', 'b', 'c']
['a', 'b', 'c']
(indexing ['a', 'b', 'c'] at 1)
a
(indexing ['a', 'b', 'c'] at 3)
c
['a', 'b', 'c', 'spam']
['spam', 'c', 'b', 'a']

This output also includes tracing text the class prints on indexing. Whether changing indexing this way is a good idea in general is another issue—users of your MyList class may very well be confused by such a core departure from Python sequence behavior. The fact that you can customize built-in types this way can be a powerful tool though, in general.

For instance, this coding pattern gives rise to an alternative way to code sets—as a subclass of the built-in list type, rather than a standalone class that manages an embedded list object. The following class, coded in the file setsubclass.py, customizes lists to add just methods and operators related to set processing. Because all other behavior is inherited from the built-in list superclass, this makes for a shorter and simpler alternative:

class Set(list):
    def _  _init_  _(self, value = []):        # Constructor
        list._  _init_  _([])                  # Customizes list
        self.concat(value)               # Copies mutable defaults

    def intersect(self, other):          # other is any sequence
        res = []                         # self is the subject
        for x in self:
            if x in other:               # Pick common items
                res.append(x)
        return Set(res)                  # Return a new Set

    def union(self, other):              # other is any sequence
        res = Set(self)                  # Copy me and my list
        res.concat(other)
        return res

    def concat(self, value):             # value: list, Set . . .
        for x in value:                  # Removes duplicates
            if not x in self:
                self.append(x)

    def _  _and_  _(self, other): return self.intersect(other)
    def _  _or_  _(self, other):  return self.union(other)
    def _  _repr_  _(self):       return 'Set:' + list._  _repr_  _(self)

if _  _name_  _ == '_  _main_  _':
    x = Set([1,3,5,7])
    y = Set([2,1,4,5,6])
    print x, y, len(x)
    print x.intersect(y), y.union(x)
    print x & y, x | y
    x.reverse(  ); print x

Here is the output of the self-test code at the end of this file. Because subclassing core types is an advanced feature, I’ll omit further details here, but I invite you to trace through these results in the code to study its behavior:

% python setsubclass.py
Set:[1, 3, 5, 7] Set:[2, 1, 4, 5, 6] 4
Set:[1, 5] Set:[2, 1, 4, 5, 6, 3, 7]
Set:[1, 5] Set:[1, 3, 5, 7, 2, 4, 6]
Set:[7, 5, 3, 1]

There are more efficient ways to implement sets with dictionaries in Python, which replace the linear scans in the set implementations shown here with dictionary index operations (hashing), and so run much quicker. (For more details, see Programming Python.) If you’re interested in sets, also take another look at the set object type we explored in Chapter 5; this type provides set operations as built-in tools. Set implementations are fun to experiment with, but they are no longer strictly required in Python today.

For another type subclassing example, see the implementation of the new bool type in Python 2.3: as mentioned earlier in the book, bool is a subclass of int with two instances (True and False) that behave like the integers 1 and 0, but inherit custom string-representation methods that display their names.

Here’s how name mangling works: names inside a class statement that start with two underscores, but don’t end with two underscores, are automatically expanded to include the name of the enclosing class. For instance, a name like _ _X within a class named Spam is changed to _Spam_ _X automatically: the original name is prefixed with a single underscore, and the enclosing class’ name. Because the modified name contains the name of the enclosing class, it’s somewhat unique; it won’t clash with similar names created by other classes in a hierarchy.

Name mangling happens only in class statements, and only for names that begin with two leading underscores. However, it happens for every name preceded with double underscores, including method names and instance attribute names (for example, in our Spam class, the instance attribute reference self._ _X would be transformed to self._Spam_ _X). Because more than one class may add attributes to an instance, this mangling helps avoid clashes—but we need to move on to an example to see how.

The problem that the pseudoprivate attribute feature is meant to alleviate has to do with the way instance attributes are stored. In Python, all instance attributes wind up in the single instance object at the bottom of the class tree. This is very different from the C++ model, where each class gets its own space for data members it defines.

Within a class method in Python, whenever a method assigns to a self attribute (e.g., self.attr = value), it changes or creates an attribute in the instance (inheritance searches only happen on reference, not on assignment). Because this is true even if multiple classes in a hierarchy assign to the same attribute, collisions are possible.

For example, suppose that when a programmer codes a class, she assumes that she owns the attribute name X in the instance. In this class’ methods, the name is set, and later fetched:

class C1:
    def meth1(self): self.X = 88         # Assume X is mine
    def meth2(self): print self.X

Suppose further that another programmer, working in isolation, makes the same assumption in a class that she codes:

class C2:
    def metha(self): self.X = 99         # Me too
    def methb(self): print self.X

Both of these classes work by themselves. The problem arises if the two classes are ever mixed together in the same class tree:

class C3(C1, C2): ...
I = C3(  )                                 # Only 1 X in I!

Now, the value that each class gets back when it says self.X will depend on which class assigned it last. Because all assignments to self.X refer to the same single instance, there is only one X attribute—I.X—no matter how many classes use that attribute name.

To guarantee that an attribute belongs to the class that uses it, prefix the name with double underscores everywhere it is used in the class, as in this file, private.py:

class C1:
    def meth1(self): self._  _X = 88       # Now X is mine
    def meth2(self): print self._  _X      # Becomes _C1_  _X in I
class C2:
    def metha(self): self._  _X = 99       # Me too
    def methb(self): print self._  _X      # Becomes _C2_  _X in I

class C3(C1, C2): pass
I = C3(  )                                 # Two X names in I

I.meth1(  ); I.metha(  )
print I._  _dict_  _
I.meth2(  ); I.methb(  )

When thus prefixed, the X attributes will be expanded to include the names of their classes before being added to the instance. If you run a dir call on I, or inspect its namespace dictionary after the attributes have been assigned, you’ll see the expanded names, _C1_ _X and _C2_ _X, but not X. Because the expansion makes the names unique within the instance, the class coders can safely assume that they truly own any names that they prefix with two underscores:

% python private.py
{'_C2_  _X': 99, '_C1_  _X': 88}
88
99

This trick can avoid potential name collisions in the instance, but note that it does not amount to true privacy. If you know the name of the enclosing class, you can still access either of these attributes anywhere you have a reference to the instance by using the fully expanded name (e.g., I._C1_ _X = 77). On the other hand, this feature makes it less likely that you will accidentally step on a class’ names.

Again, I should note that this feature tends to be more useful for larger, multi-programmer projects, and then only for selected names. Don’t be tempted to clutter your code unnecessarily; only use this feature for names that truly need to be controlled by a single class. For simpler programs, it’s probably overkill.

Perhaps the most visible change in new-style classes is their slightly different treatment of inheritance for the so-called diamond pattern of multiple inheritance trees, where more than one superclass leads to the same higher superclass further above. The diamond pattern is an advanced design concept that we have not even discussed for normal classes.

In short, with classic classes, the inheritance search procedure is strictly depth first, and then left to right—Python climbs all the way to the top, hugging the left side of the tree, before it backs up, and begins to look further to the right. In new-style classes, the search is more breadth-first in such cases—Python first looks in any superclasses to the right of the first one searched before ascending all the way to the common superclass at the top. Because of this change, lower superclasses can overload attributes of higher superclasses, regardless of the sort of multiple inheritance trees they are mixed into.

>>> class A:      attr = 1# Classic
>>> class B(A):   pass
>>> class C(A):   attr = 2
>>> class D(B,C): pass# Tries A before C
>>> x = D(  )
>>> x.attr
1

>>> class A(object): attr = 1# New style
>>> class B(A):      pass
>>> class C(A):      attr = 2
>>> class D(B,C):    pass# Tries C before A
>>> x = D(  )
>>> x.attr
2

>>> class A:      attr = 1# Classic
>>> class B(A):   pass
>>> class C(A):   attr = 2
>>> class D(B,C): attr = C.attr# Choose C, to the right
>>> x = D(  )
>>> x.attr# Works like new style
2

>>> class A(object): attr = 1# New style
>>> class B(A):      pass
>>> class C(A):      attr = 2
>>> class D(B,C):    attr = B.attr# Choose A.attr, above
>>> x = D(  )
>>> x.attr# Works like classic
1

>>> class A:
...    def meth(s): print 'A.meth'
>>> class C(A):
...     def meth(s): print 'C.meth'
>>> class B(A):
...     pass
>>> class D(B,C): pass# Use default search order
>>> x = D(  )# Will vary per class type
>>> x.meth(  )# Defaults to classic order
A.meth

>>> class D(B,C): meth = C.meth# Pick C's method: new style
>>> x = D(  )
>>> x.meth(  )
C.meth

>>> class D(B,C): meth = B.meth# Pick B's method: classic
>>> x = D(  )
>>> x.meth(  )
A.meth

class D(B,C):
    def meth(self):                   # Redefine lower
        ...
        C.meth(self)                  # Pick C's method by calling

Beyond this change in the diamond inheritance search pattern (which is itself too obscure to matter to most readers of this book), new-style classes open up a handful of even more advanced possibilities. Here’s a brief look at each.

>>> class limiter(object):
...     _  _slots_  _ = ['age', 'name', 'job']
...
>>> x = limiter(  )
>>> x.age# Must assign before use
AttributeError: age

>>> x.age = 40
>>> x.age
40
>>> x.ape = 1000# Illegal: not in slots
AttributeError: 'limiter' object has no attribute 'ape'

>>> class classic:
...     def _  _getattr_  _(self, name):
...         if name == 'age':
...             return 40
...         else:
...             raise AttributeError
...
>>> x = classic(  )
>>> x.age# Runs _  _getattr_  _
40
>>> x.name# Runs _  _getattr_  _
AttributeError

>>> class newprops(object):
...     def getage(self):
...         return 40
...     age = property(getage, None, None, None)# get,set,del,docs
...
>>> x = newprops(  )
>>> x.age# Runs getage
40
>>> x.name# Normal fetch
AttributeError: newprops instance has no attribute 'name'

>>> class newprops(object):
...     def getage(self):
...         return 40
...     def setage(self, value):
...         print 'set age:', value
...         self._age = value
...     age = property(getage, setage, None, None)
...
>>> x = newprops(  )
>>> x.age# Runs getage
40
>>> x.age = 42# Runs setage
set age: 42
>>> x._age# Normal fetch; no getage call
42
>>> x.job = 'trainer'# Normal assign; no setage call
>>> x.job# Normal fetch; no getage call
'trainer'

>>> class classic:
...     def _  _getattr_  _(self, name):# On undefined reference
...         if name == 'age':
...             return 40
...         else:
...             raise AttributeError
...     def _  _setattr_  _(self, name, value):# On all assignments
...         print 'set:', name, value
...         if name == 'age':
...             self._  _dict_  _['_age'] = value
...         else:
...             self._  _dict_  _[name] = value
...
>>> x = classic(  )
>>> x.age# Runs _  _getattr_  _
40
>>> x.age = 41# Runs _  _setattr_  _
set: age 41
>>> x._age# Defined:
no _  _getattr_  _ call
41
>>> x.job = 'trainer'# Runs _  _setattr_  _ again
>>> x.job# Defined:
no _  _getattr_  _ call

Today, there is another option for coding simple functions associated with a class. As of Python 2.2, you can code classes with static and class methods, neither of which requires an instance argument to be passed in when they are invoked. To designate such methods, classes call the built-in functions staticmethod and classmethod, as hinted in the earlier discussion of new-style classes. For example:

class Multi:
    def imeth(self, x):          # Normal instance method
        print self, x
    def smeth(x):                # Static: no instance passed
        print x
    def cmeth(cls, x):           # Class: gets class, not instance
        print cls, x
    smeth = staticmethod(smeth)  # Make smeth a static method
    cmeth = classmethod(cmeth)   # Make cmeth a class method.

Notice how the last two assignments in this code simply reassign the method names smeth and cmeth. Attributes are created and changed by any assignment in a class statement, so these final assignments overwrite the assignments made earlier by the defs.

Technically, Python now supports three kinds of class-related methods: instance, static, and class. Instance methods are the normal (and default) case that we’ve seen in this book. You must always call an instance method with an instance object. When you call it through an instance, Python passes the instance to the first (leftmost) argument automatically; when you call it through a class, you pass along the instance manually:

>>> obj = Multi(  )# Make an instance
>>> obj.imeth(1)# Normal call, through instance
<_  _main_  _.Multi instance...> 1
>>> Multi.imeth(obj, 2)# Normal call, through class
<_  _main_  _.Multi instance...> 2

By contrast, static methods are called without an instance argument; their names are local to the scopes of the classes in which they are defined, and may be looked up by inheritance. Mostly, they work like simple functions that happen to be coded inside a class:

>>> Multi.smeth(3)# Static call, through class
3
>>> obj.smeth(4)# Static call, through instance
4

Class methods are similar, but Python automatically passes the class (not an instance) in to a class method’s first (leftmost) argument:

>>> Multi.cmeth(5)# Class call, through class
_  _main_  _.Multi 5
>>> obj.cmeth(6)# Class call, through instance
_  _main_  _.Multi 6

Static and class methods are new and advanced features of the language, with highly specialized roles that we don’t have space to document fully here. Static methods are commonly used in conjunction with class attributes to manage information that spans all instances generated from the class. For example, to keep track of the number of instances generated from a class (as in the earlier example), we could use static methods to manage a counter attached as a class attribute. Because such a count has nothing to do with any particular instance, it would be inconvenient to have to access methods that process it through an instance (especially since making an instance to access the counter might change the counter). Moreover, static methods’ proximity to the class provides a more natural solution than coding class-oriented functions outside the class.

Here is the static method equivalent of this section’s original example:

class Spam:
    numInstances = 0
    def _  _init_  _(self):
        Spam.numInstances += 1
    def printNumInstances(  ):
        print "Number of instances:", Spam.numInstances
    printNumInstances = staticmethod(printNumInstances)

>>> a = Spam(  )
>>> b = Spam(  )
>>> c = Spam(  )
>>> Spam.printNumInstances(  )
Number of instances: 3
>>> a.printNumInstances(  )
Number of instances: 3

Compared to simply moving printNumInstances outside the class, as prescribed earlier, this version requires an extra staticmethod call; however, it localizes the function name in the class scope (it won’t clash with other names in the module) and moves the function code closer to where it is used (inside the class statement). You should judge for yourself whether this is a net improvement or not.

In recent Python versions, the static method designation has become even simpler; the next section explains how.

Here is an example of a user-defined decorator at work. Recall from Chapter 24 that the _ _call_ _ operator overloading method implements a function-call interface for class instances. The following code uses this to define a class that saves the decorated function in the instance and catches calls to the original name. Because this is a class, it also has state information (a counter of calls made):

class tracer:
    def _  _init_  _(self, func):
        self.calls = 0
        self.func  = func
    def _  _call_  _(self, *args):
        self.calls += 1
        print 'call %s to %s' % (self.calls, self.func._  _name_  _)
        self.func(*args)

@tracer
def spam(a, b, c):            # Wrap spam in a decorator object
    print a, b, c

spam(1, 2, 3)                  # Really calls the tracer wrapper object
spam('a', 'b', 'c')           # Invokes _  _call_  _ in class
spam(4, 5, 6)                 # _  _call_  _ adds logic and runs original object

Because the spam function is run through the tracer decorator, when the original spam name is called, it actually triggers the _ _call_ _ method in the class. This method counts and logs the call, and then dispatches to the original wrapped function. Note how the *name argument syntax is used to pack and unpack arguments passed in; because of this, this decorator can be used to wrap any function with any number of arguments.

The net effect, again, is to add a layer of logic to the original spam function. Here is the script’s output—the first line comes from the tracer class, and the second comes from the spam function:

call 1 to spam
1 2 3
call 2 to spam
a b c
call 3 to spam
4 5 6

Trace through this example’s code for more insight.

Although they are a general mechanism, function decorators are an advanced feature of interest primarily to tool writers, not application programmers, so I’ll again defer to Python’s standard manual set for more details on this subject.

Theoretically speaking, classes (and class instances) are mutable objects. Like built-in lists and dictionaries, they can be changed in-place by assigning to their attributes—and, as with lists and dictionaries, this means that changing a class or instance object may impact multiple references to it.

That’s usually what we want (and is how objects change their state in general), but this becomes especially critical to know when changing class attributes. Because all instances generated from a class share the class’ namespace, any changes at the class level are reflected in all instances unless they have their own versions of the changed class attributes.

Because classes, modules, and instances are all just objects with attribute namespaces, you can normally change their attributes at runtime by assignments. Consider the following class. Inside the class body, the assignment to the name a generates an attribute X.a, which lives in the class object at runtime, and will be inherited by all of X’s instances:

>>> class X:
...     a = 1# Class attribute
...
>>> I = X(  )
>>> I.a# Inherited by instance
1
>>> X.a
1

So far, so good—this is the normal case. But notice what happens when we change the class attribute dynamically outside the class statement: it also changes the attribute in every object that inherits from the class. Moreover, new instances created from the class during this session or program run get the dynamically set value, regardless of what the class’ source code says:

>>> X.a = 2# May change more than X
>>> I.a# I changes too
2
>>> J = X(  )# J inherits from X's runtime values
>>> J.a# (but assigning to J.a changes a in J, not X or I)
2

Is this a useful feature or a dangerous trap? You be the judge. You can actually get work done by changing class attributes without ever making a single instance; this technique can simulate “records” or “structs” in other languages. As a refresher, consider the following unusual but legal Python program:

class X: pass                       # Make a few attribute namespaces
class Y: pass

X.a = 1                             # Use class attributes as variables
X.b = 2                             # No instances anywhere to be found
X.c = 3
Y.a = X.a + X.b + X.c

for X.i in range(Y.a): print X.i    # Prints 0..5

Here, the classes X and Y work like “fileless” modules—namespaces for storing variables we don’t want to clash. This is a perfectly legal Python programming trick, but it’s less appropriate when applied to classes written by others; you can’t always be sure that class attributes you change aren’t critical to the class’ internal behavior. If you’re out to simulate a C struct, you may be better off changing instances than classes, as that way, only one object is affected:

class Record: pass
X = Record(  )
X.name = 'bob'
X.job  = 'Pizza maker'

This may be obvious, but it’s worth underscoring: if you use multiple inheritance, the order in which superclasses are listed in the class statement header can be critical. Python always searches superclasses from left to right, according to their order in the header line.

For instance, in the multiple inheritance example we saw in Chapter 25, suppose that the Super class implemented a _ _repr_ _ method, too; would we want to inherit Lister’s or Super’s? We would get it from whichever class is listed first in Sub’s class header, as inheritance searches proceed from left to right. Presumably, we would list Lister first because its whole purpose is its custom _ _repr_ _:

class Lister:
    def _  _repr_  _(self): ...

class Super:
    def _  _repr_  _(self): ...

class Sub(Lister, Super):    # Get Lister's _  _repr_  _ by listing it first

But now suppose Super and Lister have their own versions of other same-named attributes, too. If we want one name from Super, and another from Lister, the order in which we list them in the class header won’t help—we will have to override inheritance by manually assigning to the attribute name in the Sub class:

class Lister:
    def _  _repr_  _(self): ...
    def other(self): ...

class Super:
    def _  _repr_  _(self): ...
    def other(self): ...

class Sub(Lister, Super):    # Get Lister's _  _repr_  _ by listing it first
    other = Super.other      # But explicitly pick Super's version of other
    def _  _init_  _(self):
        ...

x = Sub(  )                    # Inheritance searches Sub before Super/Lister

Here, the assignment to other within the Sub class creates Sub.other—a reference back to the Super.other object. Because it is lower in the tree, Sub.other effectively hides Lister.other, the attribute that the inheritance search would normally find. Similarly, if we listed Super first in the class header to pick up its other, we would need to select Lister’s method explicitly:

class Sub(Super, Lister):                 # Get Super's other by order
    _  _repr_  _ = Lister._  _repr_  _    # Explicitly pick Lister._  _repr_  _

Multiple inheritance is an advanced tool. Even if you understood the last paragraph, it’s still a good idea to use it sparingly and carefully. Otherwise, the meaning of a name may come to depend on the order in which classes are mixed in an arbitrarily far-removed subclass. (For another example of the technique shown here in action, see the discussion of explicit conflict resolution in "New-Style Classes" earlier in this chapter.)

As a rule of thumb, multiple inheritance works best when your mix-in classes are as self-contained as possible—because they may be used in a variety of contexts, they should not make assumptions about names related to other classes in a tree. The pseudoprivate attributes feature we studied earlier can help by localizing names that a class relies on owning, and limiting the names that your mix-in classes add to the mix. In this example, for instance, if Lister only means to export its custom _ _repr_ _, it can name its other method _ _other to avoid clashing with other classes.

This gotcha went away in Python 2.2, with the introduction of nested function scopes, but I’ve retained it here for historical perspective, for readers working with older Python releases, and because it demonstrates what happens to the new nested function scope rules when one layer of the nesting is a class.

Classes introduce local scopes, just as functions do, so the same sorts of scope behavior can happen in a class statement body. Moreover, methods are further nested functions, so the same issues apply. Confusion seems to be especially common when classes are nested.

In the following example (the file nester.py), the generate function returns an instance of the nested Spam class. Within its code, the class name Spam is assigned in the generate function’s local scope. But, in versions of Python prior to 2.2, within the class’ method function, the class name Spam is not visible—method has access only to its own local scope, the module surrounding generate, and built-in names:

def generate(  ):
    class Spam:
        count = 1
        def method(self):        # Name Spam not visible:
            print Spam.count     # Not local(def), global(module), built-in
    return Spam(  )

generate(  ).method(  )

C:pythonexamples> python nester.py
Traceback (innermost last):
  File "nester.py", line 8, in ?
    generate(  ).method(  )
  File "nester.py", line 5, in method
    print Spam.count             # Not local(def), global(module), built-in
NameError: Spam

This example works in Python 2.2 and later because the local scopes of all enclosing function defs are automatically visible to nested defs (including nested method defs, as in this example). But, it doesn’t work before 2.2 (see below for some possible solutions).

Note that even in 2.2, method defs cannot see the local scope of the enclosing class; they can only see the local scopes of enclosing defs. That’s why methods must go through the self instance or the class name to reference methods and other attributes defined in the enclosing class statement. For example, code in the method must use self.count, or Spam.count, not just count.

If you’re using a release prior to 2.2, there are a variety of ways to get the preceding example to work. One of the simplest is to move the name Spam out to the enclosing module’s scope with a global declaration. Because method sees global names in the enclosing module, references to Spam will work:

def generate(  ):
    global Spam                 # Force Spam to module scope
    class Spam:
        count = 1
        def method(self):
            print Spam.count    # Works: in global (enclosing module)
    return Spam(  )

generate(  ).method(  )             # Prints 1

A better alternative would be to restructure the code such that the class Spam is defined at the top level of the module by virtue of its nesting level, rather than using global declarations. The nested method function and the top-level generate will then find Spam in their global scopes:

def generate(  ):
    return Spam(  )

class Spam:                    # Define at top level of module
    count = 1
    def method(self):
        print Spam.count       # Works: in global (enclosing module)

generate(  ).method(  )

In fact, this approach is recommended for all Python releases—code tends to be simpler in general if you avoid nesting classes and functions.

If you want to get complicated and tricky, you can also get rid of the Spam reference in method altogether by using the special _ _class_ _ attribute, which returns an instance’s class object:

def generate(  ):
    class Spam:
        count = 1
        def method(self):
            print self._  _class_  _.count       # Works: qualify to get class
    return Spam(  )

generate(  ).method(  )

When used well, the code reuse features of OOP make it excel at cutting development time. Sometimes, though, OOP’s abstraction potential can be abused to the point of making code difficult to understand. If classes are layered too deeply, code can become obscure; you may have to search through many classes to discover what an operation does.

For example, I once worked in a C++ shop with thousands of classes (some machine-generated), and up to 15 levels of inheritance. Deciphering method calls in such a complex system was often a monumental task: multiple classes had to be consulted for even the most basic of operations. In fact, the logic of the system was so deeply wrapped that understanding a piece of code in some cases required days of wading through related files.

The most general rule of thumb of Python programming applies here, too: don’t make things complicated unless they truly must be. Wrapping your code in multiple layers of classes to the point of incomprehensibility is always a bad idea. Abstraction is the basis of polymorphism and encapsulation, and it can be a very effective tool when used well. However, you’ll simplify debugging and aid maintainability if you make your class interfaces intuitive, avoid making your code overly abstract, and keep your class hierarchies short and flat unless there is a good reason to do otherwise.

These exercises ask you to write a few classes, and experiment with some existing code. Of course, the problem with existing code is that it must be existing. To work with the set class in exercise 5, either pull the class source code off the Internet (see the Preface), or type it up by hand (it’s fairly brief). These programs are starting to get more sophisticated, so be sure to check the solutions at the end of the book for pointers. You’ll find them in in Appendix B, in "Part VI, Classes and OOP.”

Figure 26-2. A scene composite with a controller class (Scene) that embeds and directs instances of three other classes (Customer, Clerk, Parrot). The embedded instance’s classes may also participate in an inheritance hierarchy; composition and inheritance are often equally useful ways to structure classes for code reuse.