Python Types and Objects

So what exactly is a Python object? An object is an axiom in our system - it is the notion of some entity. We still define an object by saying it has:

If you are more of the 'I like to know how the bits are laid out' type as opposed to the 'I like the meta abstract ideas' type, it might be useful for you to know that each object also has a specific location in main memory that you can find by calling the id() function.

The type and bases (if they exist) are important because they define special relationships an object has with other objects. Keep in mind that the types and bases of objects just other objects. This will be re-visited soon.

You might think an object has a name but the name is not really part of the object. The name exists outside of the object in a namespace (e.g. a function local variable) or as an attribute of another object.

Even a simple object such as the number 2 has a lot more to it than meets the eye.

>>> two = 2 
>>> type(two)
<type 'int'> 
>>> type(type(two))
<type 'type'> 
>>> type(two).__bases__
(<type 'object'>,) 
>>> dir(two) 
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', 
 '__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
 '__floordiv__', '__format__', '__getattribute__', '__getnewargs__',
 '__hash__', '__hex__', '__index__', '__init__', '__int__', '__invert__',
 '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', '__new__',
 '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__',
 '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__',
 '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__',
 '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__',
 '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__',
 '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__',
 'conjugate', 'denominator', 'imag', 'numerator', 'real']

You might say "What does all this mean?" and I might say "Patience! First, let's go over the first rule."

The built-in int is an object. This doesn't mean that just the numbers such as 2 and 77 are objects (which they are) but also that there is another object called int that is sitting in memory right beside the actual integers. In fact all integer objects are pointing to int using their __class__ attribute saying "that guy really knows me". Calling type() on an object just returns the value of the __class__ attribute.

Any classes that we define are objects, and of course, instances of those classes are objects as well. Even the functions and methods we define are objects. Yet, as we will see, all objects are not equal.

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 you are ready. 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.

As we introduce many different objects, we use two kinds of relationships to connect. These are the subclass-superclass relationship (a.k.a. specialization or inheritance, "man is an animal", etc.) and the type-instance relationship (a.k.a instantiation, "Joe is a man", etc.). If you are familiar with these concepts, all is well and you can proceed, otherwise you might want to take a detour through the section called “Object-Oriented Relationships”.

We examine two objects: <type 'object'> and <type 'type'>.

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

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

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. So what do we mean by type objects? Type objects share the following traits:

Yes you read that right. Types and classes are really the same in Python (disclaimer: this doesn't apply to old-style classes or pre-2.2 versions of Python. Back then types and classes had their differences but that was a long time ago and they have since reconciled their differences so let bygones be bygones, shall we?). No wonder the type() function and the __class__ attribute get you the same thing.

The term class was traditionally used to refer to a class created by the class statement. Built-in types (such as int and string) are not usually referred to as classes, but that's more of a convention thing and in reality types and classes are exactly the same thing. In fact, I think this is important enough to put in a rule:

Types and (er.. for lack of a better word) non-types (ugh!) are both objects but only types can have subcasses. Non-types are concrete values so it does not make sense for another object be a subclass. Two good examples of objects that are not types are the integer 2 and the string "hello". Hmm.. what does it mean to be a subclass of 2?

Still confused about what is a type and what is not? Here's a handy rule for you:

Looking back, you can verify that this is true for all objects we have come across, including <type 'type'> which is an instance of itself.

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'>

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

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

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.

# In Python 2.x:
class C(object): 
    pass

# In Python 3.x, the explicit base class is not required, classes are
# automatically subclasses of object:
class C: 
    pass

class D(object):
    pass

class E(C, D): 
    pass

class MyList(list): 
    pass 

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

Subclassing is only half the story.

obj = object() 

cobj = C() 

mylist = [1,2,3] 

After the above exercise, our slate looks quite full.

Figure 2.3. User Built Objects

Note that by just subclassing <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.

Various pedantic observations of the diagram above:

Also note that <type 'type'> is indeed a type of all types, and <type 'object'> a superclass 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', ..]

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'>,)

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.

Comment on this book here: discussion page. I appreciate feedback!

That's all, folks!

While we introduce many different objects, we only use two kinds of relationships (Figure 4.1, “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 4.1. 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'.

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 4.2, “Transitivity of Relationships” respectively). These properties can be directly derived from the definition of the superclass-subclass relationship.

Figure 4.2. 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 superclass-subclass 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.