简而言之,object.__init__()方法除了检查是否传入参数外什么也不做。详情请参见源代码。
当在 Service 的实例上调用时,super()调用将委托给object.__init__(),并且什么也不会发生。
但是,当在 Service 的子类的实例上调用时,情况变得更有趣。这个 super() 调用可能会委托给一个不是 Service 父类的实例的父类。关于它如何工作以及为什么有用,请参阅博客文章 Python's Super Considered Super!
以下示例(有点牵强)显示了 Service 的子类如何导致在 Service 中的 super 调用被定向到另一个名为 Color 的类:
class Service(object):
def __init__(self, host, binary, topic, manager, report_interval=None,
periodic_interval=None, *args, **kwargs):
print 'Initializing Service'
super(Service, self).__init__(*args, **kwargs)
class Color(object):
def __init__(self, color='red', **kwargs):
print 'Initializing Color'
self.color = color
super(Color, self).__init__(**kwargs)
class ColoredService(Service, Color):
def __init__(self, *args, **kwds):
print 'Initializing Colored Service'
super(ColoredService, self).__init__(*args, **kwds)
c = ColoredService('host', 'bin', 'top', 'mgr', 'ivl', color='blue')
在这个示例中,初始化按照以下顺序进行:
- 初始化彩色服务
- 初始化服务
- 初始化颜色
- 初始化对象--除参数检查外不做任何操作
ColoredService
构造函数允许传递foo='bar'
等参数,但最终会出现TypeError: object.__init__() takes no parameters
错误。那么在Service
和Color
类的super
调用中传递*args
和**kwargs
的意义是什么呢?实际上,在没有它们的情况下,您的示例也可以正常工作(并且更加健壮)。 - ekhumoro*args
部分是他们代码中的一部分,调用者必须尊重这个签名。我只是添加了Color和ColoredService来展示MRO如何从Service到Color再到object进行链式调用。 - Raymond Hettinger