Python Types and Objects

In the pre 2.2 world, we essentially had three kinds of objects to play with - we had the:

Types and classes were known not to socialize, and you couldn't create new types. The new (2.2 and later) system moves around many of the old rules, and it is best to start afresh to understand it better. From here on we only discuss the new system.

So what exactly is an object? An object is an axiom in our system - it is the notion of some thing. However, we still define an object by saying it has:

This brings us to our first rule.

Not to be taken too seriously, but this rule does make an important point. The list, tuple and string built-ins are objects. Any classes that we define are objects, and of course, instances of those classes are objects as well. Yet, as we will see, all objects are not equal. We keep the notion of objects and relationships at this point and move on.

We now build the Python object system from scratch. Let us begin at the beginning - with a clean slate.

Figure 1.1. A Clean Slate

You might be wondering why a clean slate has two grey lines running vertically through it. All will be revealed when the time is right. For now this will help distinguish a slate from another figure. On this clean slate, we will gradually put different objects, and draw various relationships, till it is left looking quite full.

At this point, it helps if any preconceived object oriented notions of classes and objects are set aside, and everything is perceived in terms of objects (our objects) and relationships.

While we introduce many different objects, we only use two kinds of relationships (Figure 1.2, “Relationships”):

Note that in plain English, the term 'is a' is used for both of the above relationships. Squasher is a snake and snake is a reptile are both correct. We, however, use specific terms from above to avoid any confusion.

Figure 1.2. Relationships

We use the solid line for the first relationship because these objects are closer to each other than ones related by the second. To illustrate - if one is asked to list words similar to 'snake', one is likely to come up with 'reptile'. However, when asked to list words similar to 'Squasher', one is unlikely to say 'snake'. One might (if one knew the names of the author's other pets) instead come up with 'Squisher', 'Stinger' and 'Hisser'.

It is useful at this point to note the following (independent) properties of relationships:

In other words, the head end of a dashed arrow can move up a solid arrow, and the tail end can move down (shown as 2a and 2b in Figure 1.3, “Transitivity of Relationships” respectively). These properties can be directly derived from the definition of the supertype-subtype relationship.

Figure 1.3. Transitivity of Relationships

Applying Dashed Arrow Up Rule, we can derive the second statement from the first:

Earlier we said that an object has exactly one type. So how does Squasher have two? Note that although both statements are correct, one is more correct (and in fact subsumes the other). In other words:

A similar rules exists for the supertype-subtype relationship.

A snake is a kind of reptile, and a reptile is a kind of animal. Therefore a snake is a kind of animal. Or, in Pythonese:

Note that it is possible for an object to have more than one base.

Now that we have our objects and relationships, let's get started. We first try to examine two as of yet mysterious objects <type 'object'> and <type 'type'>.

>>> object 
<type 'object'>
>>> type 
<type 'type'> 
>>> object.__class__ 
<type 'type'>
>>> object.__bases__ 
()
>>> type.__class__ 
<type 'type'>
>>> type.__bases__ 
(<type 'object'>,)

	The names of the objects within Python.
	Discovering relationships.

Let's make use of our slate and draw what we've seen.

Figure 2.1. Chicken and Egg

These two objects are primitive objects in Python. We might as well have introduced them one at a time but that would lead to the chicken and egg problem - which to introduce first? These two objects are interdependent - they cannot stand on their own since they are defined in terms of each other.

Continuing our Python experimentation:

>>> isinstance(object, object) 
True
>>> isinstance(type, object) 
True

	Whoa! What happened here? This is just Dashed Arrow Up Rule in action. Since <type 'type'> is a subtype of <type 'object'>, instances of <type 'type'> are instances of <type 'object'> as well.
	Applying both Dashed Arrow Up Rule and Dashed Arrow Down Rule, we can effectively reverse the direction of the dashed arrow. Yes, it is still consistent.

If the above example proves too confusing, ignore it - it is not much use anyway.

Now for a new concept - type objects. Both the objects we introduced are type objects.

What do we mean by type objects? As we already know, not all objects are equal. In fact, an object can be either a type object or a non-type object. It takes a certain personality to be the 'type of' another object. Objects with this personality are called type objects. Such objects can participate in a type-instance relationship on the type side (as well as instance side). Non-type objects are doomed to always participate only on the instance side.

Also, only type objects can be the 'supertype of' another object. Apparently, you need a strong personality for this as well. In reality, non-type objects are so concrete that it does not make sense for something else to be a subtype. If you still disagree, try to fill in the blank: ________ is a kind of Squasher.

As you guessed, Squasher is a non-type object, and 'snake' is a type object.

Type objects are also lovingly called types. The strong personality of types gets passed down to subtypes, as a result all subtypes of a type object are types themselves.

To summarize:

Note that we are drawing arrows on our slate for only the direct relationships, not the implied ones (i.e. only if one object is another's __class__, or in the other's __bases__). This make economic use of the slate and our mental capacity.

Figure 2.2. Some Built-in Types

A few built-in types are shown above, and examined below.

>>> list 
<type 'list'>
>>> list.__class__  
<type 'type'>
>>> list.__bases__  
(<type 'object'>,)
>>> tuple.__class__, tuple.__bases__ 
(<type 'type'>, (<type 'object'>,))
>>> dict.__class__, dict.__bases__ 
(<type 'type'>, (<type 'object'>,))
>>>
>>> mylist = [1,2,3] 
>>> mylist.__class__ 
<type 'list'>

	The built-in <type 'list'> object.
	Its type is <type 'type'>.
	It has one supertype, <type 'object'>.
	Ditto for <type 'tuple'> and <type 'dict'>.
	This is how you create an instance of <type 'list'>.
	How refreshing! For the first time an object that has an object other than <type 'type'> as its type.

When we create a tuple or a dictionary, they are instances of the respective type objects.

So how can we create an instance of mylist? We cannot. This is because mylist is a non-type object.

We are now in a position to better define type objects.

Looking back, we can verify that this is true for all objects we have come across.

The built-in objects are, well, built into Python. They're there when we start Python, usually there when we finish. So how can we create new objects?

New objects cannot pop out of thin air. They have to be built using existing objects. Specifically, we can only create objects that are at the tail-end of a relationship (i.e. tail-end of an arrow).

class C(object): 
    pass 

class D(object):
    pass

class E(C, D): 
    pass

class MyList(list): 
    pass 

	The class statement tells Python to create a new type object by subtyping an existing type object.
	The body of a class definition would usually provide useful methods and more.
	Multiple bases are fine too.
	Most built-in types can be subtyped (but not all).

After the above example, C.__bases__ contains <type 'object'>, and MyList.__bases__ contains <type 'list'>.

The term class is traditionally used to imply an object created by the class statement. However, classes are now synonymous with types. Built-in types are usually not referred to as classes. This book prefers using the term type for both built-in and user created types.

Subtyping is only half the story.

obj = object() 

cobj = C() 

mylist = [1,2,3] 

	The call operator (()) creates a new object by instantiating an existing object. The existing object must be a type object. Depending on the type object, the call operator might accept arguments.
	Python syntax creates new objects for some built-in types. (The square brackets create an instance of <type 'list'>, for example).

After the above exercise, our slate looks quite full.

Figure 2.3. User Built Objects

Note that by just subtyping <type 'object'>, the type C automatically is an instance of <type 'type'>. This can be verified by checking C.__class__. Why this happens is explained in the next section.

Some questions are probably popping up in your head at this point. Or maybe they aren't, but I'll answer them anyway:

class MyCWithSpecialType(object):
    __metaclass__ = SpecialType

We really ended up with a map of different kinds of Python objects in the last chapter.

Figure 3.1. The Python Objects Map

Here we also unravel the mystery of the vertical grey lines. They just segregate objects into three spaces based on what the common man calls them - metaclasses, classes, or instances.

Some interesting points to note:

Also note that <type 'type'> is indeed a type of all types, and <type 'object'> a supertype of all types (except itself).

The following example shows how to discover and experiment with built-in types.

>>> import types 
>>> types.ListType is list 
True
>>> def f(): 
...     pass
...
>>> f.__class__ is types.FunctionType 
True
>>>
>>> class MyList(list): 
...     pass
...
>>> class MyFunction(types.FunctionType): 
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: type 'function' is not an acceptable base type
>>> dir(types) 
['BooleanType', 'DictProxyType', 'DictType', ..]

	The types module contains many built-in types.
	Some well known types have another name as well.
	def creates a function object.
	The type of a function object is types.FunctionType
	Some built-in types can be subtyped.
	Some cannot.
	More types than you can shake a stick at.

So we can create new objects with any relationship we choose, but what does it buy us?

The relationships between objects determine how attribute access on the object works. For example, when we say objectname.attributename, which object do we end up with? It all depends on objectname, its type, and its bases (if they exist).

Attribute access mechanisms in Python are explained in the second book of this series: Python Attributes and Methods.

This is a note about classic classes in Python. We can create classes of the old (pre 2.2) kind by using a plain class statement.

>>> class ClassicClass: 
...     pass
...
>>> type(ClassicClass) 
<type 'classobj'>
>>> import types
>>> types.ClassType is type(ClassicClass) 
True
>>> types.ClassType.__class__ 
<type 'type'>
>>> types.ClassType.__bases__ 
(<type 'object'>,)

	A class statement specifying no bases creates a classic class. Specifying only classic classes as bases also creates a classic class. Specifying both classic and new-style classes as bases create a new-style type.
	Its type is an object we haven't seen before (in this book).
	The type of classic classes is an object called types.ClassType.
	It looks and smells like just another type object.

The types.ClassType object is in some ways an alternative <type 'type'>. Instances of this object (classic classes) are types themselves. The rules of attribute access are different for classic classes and new-style classes. The types.ClassType object exists for backward compatibility and may not exist in future versions of Python. Other sections of this book should not be applied to classic classes.

That's all, folks!