Up to Python 2.1, old-style classes were the only flavour available to the user.
The concept of (old-style) class is unrelated to the concept of type:
if x
is an instance of an old-style class, then x.__class__
designates the class of x
, but type(x)
is always <type
'instance'>
.
This reflects the fact that all old-style instances, independently of
their class, are implemented with a single built-in type, called
instance.
New-style classes were introduced in Python 2.2 to unify the concepts of class and type.
A new-style class is simply a user-defined type, no more, no less.
If x is an instance of a new-style class, then type(x)
is typically
the same as x.__class__
(although this is not guaranteed – a
new-style class instance is permitted to override the value returned
for x.__class__
).
The major motivation for introducing new-style classes is to provide a unified object model with a full meta-model.
It also has a number of immediate benefits, like the ability to
subclass most built-in types, or the introduction of "descriptors",
which enable computed properties.
For compatibility reasons, classes are still old-style by default.
New-style classes are created by specifying another new-style class
(i.e. a type) as a parent class, or the "top-level type" object if no
other parent is needed.
The behaviour of new-style classes differs from that of old-style
classes in a number of important details in addition to what type
returns.
Some of these changes are fundamental to the new object model, like
the way special methods are invoked. Others are "fixes" that could not
be implemented before for compatibility concerns, like the method
resolution order in case of multiple inheritance.
Python 3 only has new-style classes.
No matter if you subclass from object
or not, classes are new-style
in Python 3.
Best Answer
The most obvious problem is with function overriding.
Let's say have two classes
A
andB
, both of which define a methoddoSomething
. Now you define a third classC
, which inherits from bothA
andB
, but you don't override thedoSomething
method.When the compiler seed this code...
...which implementation of the method should it use? Without any further clarification, it's impossible for the compiler to resolve the ambiguity.
Besides overriding, the other big problem with multiple inheritance is the layout of the physical objects in memory.
Languages like C++ and Java and C# create a fixed address-based layout for each type of object. Something like this:
When the compiler generates machine code (or bytecode), it uses those numeric offsets to access each method or field.
Multiple inheritance makes it very tricky.
If class
C
inherits from bothA
andB
, the compiler has to decide whether to layout the data inAB
order or inBA
order.But now imagine that you're calling methods on a
B
object. Is it really just aB
? Or is it actually aC
object being called polymorphically, through itsB
interface? Depending on the actual identity of the object, the physical layout will be different, and its impossible to know the offset of the function to invoke at the call-site.The way to handle this kind of system is to ditch the fixed-layout approach, allowing each object to be queried for its layout before attempting to invoke the functions or access its fields.
So...long story short...it's a pain in the neck for compiler authors to support multiple inheritance. So when someone like Guido van Rossum designs python, or when Anders Hejlsberg designs c#, they know that supporting multiple inheritance is going to make the compiler implementations significantly more complex, and presumably they don't think the benefit is worth the cost.