• Choose a category
• All
• Classic-Fiction

C:\misc> c:\python26\python classtree.py

Tree of <__main__.B instance at 0x02557328>

...B

......A

Tree of <__main__.F instance at 0x02557328>

...F

......D

.........B

............A

.........C

............A

......E

When run under Python 3.0, the tree includes the implied object superclasses that are automatically added above standalone classes, because all classes are “new style” in 3.0 (more on this change in Chapter 31):

C:\misc> c:\python30\python classtree.py

Tree of <__main__.B object at 0x02810650>

...B

......A

.........object

Tree of <__main__.F object at 0x02810650>

...F

......D

.........B

............A

...............object

.........C

............A

...............object

......E

.........object

Here, indentation marked by periods is used to denote class tree height. Of course, we could improve on this output format, and perhaps even sketch it in a GUI display. Even as is, though, we can import these functions anywhere we want a quick class tree display:

C:\misc> c:\python30\python

>>> class Emp: pass

...

>>> class Person(Emp): pass

>>> bob = Person()

>>> import classtree

>>> classtree.instancetree(bob)

Tree of <__main__.Person object at 0x028203B0>

...Person

......Emp

.........object

Regardless of whether you will ever code or use such tools, this example demonstrates one of the many ways that you can make use of special attributes that expose interpreter internals. You’ll see another when we code the lister.py general-purpose class display tools in the section Multiple Inheritance: “Mix-in” Classes—there, we will extend this technique to also display attributes in each object in a class tree. And in the last part of this book, we’ll revisit such tools in the context of Python tool building at large, to code tools that implement attribute privacy, argument validation, and more. While not for every Python programmer, access to internals enables powerful development tools.

* * *

[67] As you can see, the contents of attribute dictionaries and dir call results may change over time. For example, because Python now allows built-in types to be subclassed like classes, the contents of dir results for built-in types have expanded to include operator overloading methods, just like our dir results here for user-defined classes under Python 3.0. In general, attribute names with leading and trailing double underscores are interpreter-specific. Type subclasses will be discussed further in Chapter 31.

Documentation Strings Revisited

The last section’s example includes a docstring for its module, but remember that docstrings can be used for class components as well. Docstrings, which we covered in detail in Chapter 15, are string literals that show up at the top of various structures and are automatically saved by Python in the corresponding objects’ __doc__ attributes. This works for module files, function defs, and classes and methods.

Now that we know more about classes and methods, the following file, docstr.py, provides a quick but comprehensive example that summarizes the places where docstrings can show up in your code. All of these can be triple-quoted blocks:

"I am: docstr.__doc__"

def func(args):

"I am: docstr.func.__doc__"

pass

class spam:

"I am: spam.__doc__ or docstr.spam.__doc__"

def method(self, arg):

"I am: spam.method.__doc__ or self.method.__doc__"

pass

The main advantage of documentation strings is that they stick around at runtime. Thus, if it’s been coded as a docstring, you can qualify an object with its __doc__ attribute to fetch its documentation:

>>> import docstr

>>> docstr.__doc__

'I am: docstr.__doc__'

>>> docstr.func.__doc__

'I am: docstr.func.__doc__'

>>> docstr.spam.__doc__

'I am: spam.__doc__ or docstr.spam.__doc__'

>>> docstr.spam.method.__doc__

'I am: spam.method.__doc__ or self.method.__doc__'

A discussion of the PyDoc tool, which knows how to format all these strings in reports, appears in Chapter 15. Here it is running on our code under Python 2.6 (Python