由于python中包含多重继承机制，那么子类在多重继承中，到底用的是哪一个超类的方法就是大家关心的问题，之前在查阅已有书籍无果后，只得去翻官方文档与博客，终于得解，于是在此总结归纳。
全称 方法解析顺序（Method Resolution Order) 简称为 MRO 这个东西就是来解决多重继承的解析问题的，如果一般只关心顺序，不关心解析顺序怎么来的话，只要用类下的__ mro __的特殊方法，即可得到解析顺序链。
python3与python2.2之前的解析方法并不相同，至于原因嘛，往下看就知道了。
举个例子：
Python 2.2 进行解析的顺序可以看做 广度优先 ，该结构在python2.2之前能够正常解析为[F, A, B, X, Y]的解析链。
首先我们看下各个类中的方法解析顺序：这里A，B只有一层父子继承关系，根据继承的左右顺序容易得出继承链,(python2.2)与C3这时效果相同，对于 A 来说，其搜索顺序为 [A, X, Y]；对于 B，其搜索顺序为 [B, Y, X]；
关键在对于 F的解析上，python2.2之前其搜索顺序为 [F, A, B, X, Y]。
这样的结果是否合理呢？
对于F的继承顺序python3如何求解呢？
为了方便展示算法逻辑，首先规定几个约定:
1.[c1, c2, c3, c4 .... cN] 代表N个类的解析列表
2.c1 + [c2, c3, c4 .... cN] = [c1, c2, c3, c4 .... cN] #解析列表的拼接方式
3.head([c1, c2, c3, c4 .... cN]) = c1 #取一个列表的头部
4.tail([c1, c2, c3, c4 .... cN]) = [c2, c3, c4 .... cN] #剔除掉列表头部的剩余部分
那么就从下面这个公式中展开，就是对merge的操作递归
#假设类C继承自父类b1 b2 b3,那么C的继承链如下
L[c] = c + merge(L[b1], L[b2], L[b3], b1, b2, b3)
c3算法流程
1.取出merge中第一个列表K1
2.取出h = head(K1)，遍历后续解析列表中所有的tail(KN),若tail中没有出现了h，就将h从merge中所有列表中清除，并循环2
3.若当前的h不符合要求则替换下一个K
4.若merge中所有的类被清除则正常输出继承解析列表，否则则抛出异常
好了对于F来说我们一步步来推导：
L[A] = [A, X, Y]
L[B] = [B, Y, X]
L[F] = F + merge(L[A], L[B] , A, B)
L[F] = F + merge([A, X, Y], [B, Y, X] , A, B)
这时让我们开始跑merge
L[F] = [F,A] + merge([X, Y], [B, Y, X] , B) (1)
L[F] = [F,A,B] + merge([X, Y], [Y, X]) (2)
然而当继续往下执行的时候C3算法会抛出异常
L[F] = [F,A,B] + merge([X, Y], [Y, X]) (3)
因为所有解析列表已经遍历完，但是merge中的类并没有清除完成。
那么C3算法为何要这么设计？
仔细看由python2.2之前推导的继承链我们会发现，B 和 F 中 X、Y 的搜索顺序是相反的！也就是说，当 B 被继承时，它本身的继承链竟然也发生了改变，这很容易导致不易察觉的大坑。
C3算法 秉承的原则是子类形成的继承链，应该能完整的继承超类的继承链，而不是对超类的继承链进行改造而适配子类的继承链。因此python2.2在大量的多重继承后会引发意想不到的BUG，而当你的继承链出现类似例子中的情况时，C3则会抛出异常，提前终止你的不当继承行为。以上是个人的一些理解，如有不对可以评论探讨。
相关资料：
Python Tutorial: Understanding Python MRO - Class search path
The Python 2.3 Method Resolution Order