class A:def save(self): pass
class B(A): pass
class C:def save(self): pass
class D(B, C): pass

作为D类的一个实例，它的成员寻找顺序是：D、B、A、C。
但当碰到如下这样一个“菱形继承”就麻烦了：

class A:def save(self): pass
class B(A): pass
class C(A):def save(self): pass
class D(B, C): pass

作为D类的一个实例，寻找顺序也是D、B、A、C，但调用其save方法时，到底是调用A中的呢？还是C中的呢？直观上看，应该是C。这里有产生矛盾了。
2. Python2.2的new-style class模式
Python2.2中引进了new-style class，说白了就像java一样，所有类都继承自最根本的object类。
这就让“菱形继承”变成十分普遍，于是只能改变MRO策略。
仍然使用深度优先搜索、从左向右，但是每个类选择其最后一次出现的位置。
这样一来，对上面的“菱形继承”就处理比较完美了，形成的顺序是：D、B、C、A，越是公用基础类，越放在后面。
但是，碰到交叉继承，就又懵了。
<img src="https://pic4.zhimg.com/d067bccb353065c3276a96f6aab93a77_b.jpg" data-rawwidth="113" data-rawheight="179" class="content_image" width="113">这里，X和Y都继承自O，A继承(X,Y)（注意，有先后顺序），B继承(Y,X)，再有个最下面的类继承(A,B)。这里，X和Y都继承自O，A继承(X,Y)（注意，有先后顺序），B继承(Y,X)，再有个最下面的类继承(A,B)。
按照上述算法出来的结果是：?、A、B、Y、X、O。这就有些奇怪了，明明A在B前，A继承的X在Y前，可为啥X的优先级比Y要低呢？
3. C3算法
1996年，一帮牛人写了一篇文章A monotonic superclass linearization for Dylan，提供了一个基于层级计算的线性MRO算法，被称为C3，整体上比较合理了。（算法不详说了）
在2012年被加入了Dylan语言，2007年加入了Python2.3，此外还有Perl 6、Parrot等语言之中。
这样虽说基本解决了计算问题，但多重继承本身就有很多让人疑惑的地方，比如：
<img src="https://pic4.zhimg.com/c1e6e9a3a1df789b9686582a9367326b_b.jpg" data-rawwidth="251" data-rawheight="171" class="content_image" width="251">参考文献：参考文献：
http://python-history.blogspot.jp/2010/06/method-resolution-order.html
The Python 2.3 Method Resolution Order
============================================
第二部分：
多重继承那么复杂，可单一继承又那么拘束，咋办呢？
1. 接口继承
Java就是那么做的，只允许单一继承类（方法的实现），但可以继承多个接口（方法的定义）。

Java的接口继承功能，既实现了静态语言的多重继承性，又避免了多重继承的数据构造的冲突和类层次的复杂性。
但是，我们并不能说接口是解决问题的完美方案。接口也有不能共享实现的缺点。
本来只是为了跨越继承层次来共享代码，现在却需要另外生成一个独立对象，而且每次方法调用都要委派给这个对象，这实在是不太合理，而且执行的效率也不高。
——《松本行弘的程序世界》

2. Mix-in
这是Ruby所推崇的，最初在Lisp中开始使用。规则如下：

1. 通常的继承都是单一继承。
2. 第二个以及两个以上的父类必须是Mix-in的抽象类（即不能单独生成实例，不能继承普通类）。

这种规则下，既能够保持单一继承的结构，又能用Mix-in来共享方法的实现。