Python继承机制中的object
在python的面向对象编程中，object是一个非常特殊的类。它是所有类的终极基类（ultimate base class）。这意味着无论你显式地声明与否，python中的每一个类，最终都会继承自object。
特别是在Python 3中，所有的类都是“新式类”（new-style classes），它们默认就继承自object。这意味着以下两种类定义在功能上是等价的：
class MyClass:
pass
class MyClass(object):
pass在Python 2中，为了创建新式类，必须显式地继承自object。但在Python 3中，这已不再是必需。
显式继承object的两种常见场景
假设我们有一个基类Foo，它已经隐式或显式地继承自object。现在我们想定义一个子类Bar。我们可能会遇到两种定义方式：
-
隐式继承object：
立即学习“Python免费学习笔记（深入）”；
class Bar(Foo): pass在这种情况下，Bar直接继承Foo，而Foo本身已经构成了到object的继承链。
-
显式多重继承object：
class Bar(Foo, object): pass在这种情况下，Bar显式地从Foo和object进行多重继承。
那么，这两种方式在功能上是否存在差异？
方法解析顺序（MRO）的分析
Python使用C3线性化算法来确定多重继承中的方法解析顺序（Method Resolution Order, MRO）。MRO决定了当一个方法被调用时，Python解释器会按照哪个顺序在类的继承链中查找该方法。
让我们通过示例来观察这两种定义方式对MRO的影响：
class Foo:
pass
# 方式一：Bar(Foo)
class Bar1(Foo):
pass
print(f"Bar1的MRO: {Bar1.mro()}")
# 方式二：Bar(Foo, object)
class Bar2(Foo, object):
pass
print(f"Bar2的MRO: {Bar2.mro()}")运行上述代码，你会得到如下输出：
Bar1的MRO: [, , ] Bar2的MRO: [ , , ]
可以看到，无论Bar是Bar(Foo)还是Bar(Foo, object)，它们的方法解析顺序都是完全相同的。这是因为C3线性化算法会确保object作为所有类的最终基类，只会在MRO的末尾出现一次。即使你显式地将其列为基类之一，它也不会被重复添加或改变其在继承链中的最终位置。因此，从方法查找和执行的角度来看，这两种方式没有功能上的区别。
__bases__属性的差异
尽管MRO没有变化，但在类的内部属性上，这两种定义方式存在一个细微的差异，即__bases__属性。__bases__是一个元组，存储了当前类直接继承的所有基类。
class Foo:
pass
# 方式一：Bar(Foo)
class Bar1(Foo):
pass
print(f"Bar1的__bases__: {Bar1.__bases__}")
# 方式二：Bar(Foo, object)
class Bar2(Foo, object):
pass
print(f"Bar2的__bases__: {Bar2.__bases__}")运行上述代码，你会得到如下输出：
Bar1的__bases__: (,) Bar2的__bases__: ( , )
从输出可以看出，Bar1.__bases__只包含Foo，而Bar2.__bases__则包含了Foo和object。这个差异反映了类定义时显式声明的基类列表。
实践建议与总结
在绝大多数情况下，显式地在多重继承中包含object（例如class Bar(Foo, object):）是没有实际功能性好处的，尤其是在Python 3中。
- 冗余性： 由于object是所有类的终极基类，并且Python的MRO算法会正确处理继承链，显式声明它通常是多余的。
-
潜在原因： 这种写法可能源于以下几种情况：
- Python 2兼容性代码： 在Python 2中，为了确保类是新式类，必须显式继承object。代码迁移时可能未移除。
- 个人习惯或误解： 开发者可能认为显式声明能更清晰地表达意图，或对MRO有误解。
- 罕见的内省需求： 极少数情况下，如果代码需要严格地通过__bases__属性来检查类声明时的直接基类，那么这种差异可能会有影响。但这种需求非常罕见，且通常可以通过MRO或其他内省方式达到目的。
- 最佳实践： 为了代码的简洁性和可读性，推荐在Python 3中避免不必要的显式object继承。遵循“只做必要的事情”的原则，让Python的默认行为（所有类隐式继承object）来处理即可。
综上所述，虽然显式继承object不会破坏代码功能，但它通常是冗余的，并且在Python 3中没有实际的必要性。除非你面临非常特殊且明确需要__bases__属性反映显式声明的场景，否则应选择更简洁的class Bar(Foo):写法。
