The relationship between type and object in Python for Python face question

What you see on the question:

The two are mutual instances of the relationship, but not the relationship between the sub-class, only the type is a subclass of object, the other is not true. Daniel said that the two are egg-born chicken eggs, but I still do not understand, have to understand the trouble to explain, I hope not to give a link to the foreign language. Why does Python design two, remove a line?

Here's the answer from Jeff Kit:
explained to others many times, but writing is the first time. Try it, and I read this article (Python Types and Objects). The relationship between object and type is much like the relationship between chicken and egg, first there is an object or first type cannot say, obejct and type are symbiotic relationship, must appear at the same time. Before looking at it, please understand that in Python, everything is the object concept. In the object-oriented system, there are two kinds of relationship:-The parent-child relationship, that is, the inheritance of the child class inherits from the parent class, such as "Snake" class inherits from "reptile" class, we say "Snake is a kind of reptile", English said "Snake is a kind of reptile". In Python, to see the parent class of a type, use its bases property to view it. -type instance relationship, which behaves as an instantiation of a type, such as "Meng Meng is a snake", English said "Meng Meng is a instance of snake". In Python, to see the type of an instance, use its class property to view it, or use the type () function to view it. These two relationships use the following diagram to simply indicate that an inheritance relationship uses a solid line from child to parent connection, and type instance relationships use dashed lines from instance to type connections:

We will use a whiteboard to describe the relationship between objects in Python, and the whiteboard is divided into three columns:

First look at type and object:
>>> Object
<type ' object ' >
>>> type
<type ' type ' >
They are all instances of type, indicating that they are all types of objects.

In the world of Python, object is the top of a parent-child relationship, and all of the data types are the parent class, and type is the top of the type instance relationship, and all objects are instances of it. Their two relationships can be described as:

-Object is a type,object is an instance of type. That is, object is an instance of type.

>>> object.__class__
<type ' type ' >
>>> object.__bases__ # object has no parent class because it is the top of the chain.
()

-Type is an object, type is kind of object. That is, the type is a subclass of object.

>>> type.__bases__
(<type ' object ';,)
>>> type.__class__ # type is its own
<type ' type ' >

At this point, the relationship of objects on the whiteboard is as follows:

Let's take a look at the built-in data types of list, dict, and tuple:
>>> list.__bases__
(<type ' object ';,)
>>> list.__class__
<type ' type ' >
>>> dict.__bases__
(<type ' object ';,)
>>> dict.__class__
<type ' type ' >
>>> tuple.__class__
<type ' type ' >
>>> tuple.__bases__
(<type ' object ';,)
Both of their parent classes are object, and the types are type.

Then instantiate a list to see:
>>> mylist = [+]
>>> mylist.__class__
<type ' list ' >
>>> mylist.__bases__
Traceback (most recent):
File "<stdin>", line 1, in <module>
Attributeerror: ' List ' object has no attribute ' __bases__ '
The type of the instantiated list is <type ' list ', without the parent class.

Add them to the Whiteboard:

A dashed line on the whiteboard indicates that the source is an instance of the destination, and the solid lines indicate that the source is a subclass of the target. That is, the left side is the right type, and the top is the following father.
Dashed lines produce relationships across columns, while solid lines can only produce relationships within one column. Except for type and object.

What does it have to do with the objects above when we set a class and instantiate it ourselves? Try it:

>>> class C (object):
... pass
...
>>> c.__class__
<type ' type ' >
>>> c.__bases__
(<type ' object ';,)

Instantiation of
>>> C = C ()
>>> c.__class__
<class ' __main__. C ' >
>>> c.__bases__
Traceback (most recent):
File "<stdin>", line 1, in <module>
Attributeerror: ' C ' object has no attribute ' __bases__ '
This instantiated Class C object is also not a property of the parent class.
Then update the whiteboard:

The first column on the Whiteboard, currently only type, we first call this list of things type.
The second column on the Whiteboard, which is both the type of the third column and the instance of the first column, we call this column the object typeobject.
The third column on the Whiteboard, which is an instance of the second column type, without the parent class (__BASES__), we call them instance.

You think this is the end of the story? No.. Seeing the type alone in the first column is actually not so comfortable. Let's give it a whole couple of playmates to see. But how to complete it? To belong to the first column must be a subclass of type, then we just need to inherit the type to define the class:
>>> class M (type):
... pass
...
>>> m.__class__
<type ' type ' >
>>> m.__bases__
(<type ' type ';,)
>>>
Well, the class m and the parent class are type. This time, we can put it in the first column. So, how do you instantiate the M type? After instantiation, should it appear in that column? Well, well, just now you accidentally created a meta class, metaclass! Class that is the class. If you are instantiating a meta-class, you have to define a class:
>>> class TM (object):
... __metaclass__ = M # To specify a meta-class.
...
...
>>> tm.__class__
<class ' __main__. M ' > # This class is no longer a type, but an M type.
>>> tm.__bases__
(<type ' object ';,)

Well, now the TM class is in the second column.

Let's summarize:
The first column, the Meta-class column, and the type are the fathers of all meta-classes. We can create a meta class by inheriting the type.
The second column, Typeobject column, also called Class column, object is the father of all classes, and most of the data types we use directly exist in this column.
The third column, the instance column, is the end of the object relationship chain and cannot be overridden and instantiated.

Until now, the secret of the Python type has been revealed, and the Meta class has been exposed. Hey. Slowly digest it, the amount of information is very large.

============= Update =============
Update Update: Answer the question why do you have two, not one, behind the problem? If type and object hold only one, then it must be an object. With only object, the first column will no longer exist, only two or three columns are left, the second column represents the type, and the third column represents the instance, which is similar to the type schema for most static languages, such as Java. Such an architecture would leave Python with a very important dynamic feature – dynamically created types. Originally, the Class (the second column of the classmate) in Python is an object (Typeobject), the object can be dynamically modified at runtime, so we can after you define a class to modify his behavior or properties! After taking out the first column, the second column becomes a pure type, written as what, and run-time behavior. At this point, there is no advantage over static language. So, above!
============= Supplement =============
Add a brief answer to the question by another person who knows
Liu Xin
Simply put, many runtime systems (not necessarily for a particular language) provide the ability to get type information at run time, and what is obtained? Gets an object that describes the type information. Then all objects that describe the type information are instances of type type. This type is not the type itself, but an object instance that describes the type, which is an abstract information, and the instance object of the type class is its specific information vector. Since type is also a type, it is a derivation of the common root type object, which is a reasonable design. In turn, the object type does not depend on the type, and at most some of its reflection/introspection logic needs to call the type.

Reference

The relationship between type and object in Python for Python face question