Метод разрешения разрешения (MRO) в классах нового стиля?
В книге Python в двух словах (2-е издание) есть пример, который использует
старые классы стиля, чтобы продемонстрировать, как методы решаются в классическом порядке разрешения и
как это отличается от нового порядка.
Я попробовал такой же пример, переписав пример в новом стиле, но результат не отличается от того, что было получено в классах старого стиля. Версия python, используемая для запуска примера, 2.5.2. Ниже приведен пример:
class Base1(object):
def amethod(self): print "Base1"
class Base2(Base1):
pass
class Base3(object):
def amethod(self): print "Base3"
class Derived(Base2,Base3):
pass
instance = Derived()
instance.amethod()
print Derived.__mro__
Вызов instance.amethod()
выводит Base1
, но в соответствии с моим пониманием MRO с новым стилем классов вывод должен быть Base3
. Вызов Derived.__mro__
печатает:
(<class '__main__.Derived'>, <class '__main__.Base2'>, <class '__main__.Base1'>, <class '__main__.Base3'>, <type 'object'>)
Я не уверен, что мое понимание MRO с новыми классами стиля неверно или что я делаю глупую ошибку, которую я не могу обнаружить. Пожалуйста, помогите мне лучше понять MRO.
Ответы
Ответ 1
Решающее различие между порядком разрешения для классов legacy vs new-style возникает, когда один и тот же класс предков происходит более одного раза в "наивном", основанном на глубине подходе - например, рассмотрим случай "наследования алмазов":
>>> class A: x = 'a'
...
>>> class B(A): pass
...
>>> class C(A): x = 'c'
...
>>> class D(B, C): pass
...
>>> D.x
'a'
здесь, унаследованный стиль, порядок разрешения - D - B - A - C - A: поэтому при поиске Dx A является первой базой в разрешении для ее решения, тем самым скрывая определение в C. Хотя:
>>> class A(object): x = 'a'
...
>>> class B(A): pass
...
>>> class C(A): x = 'c'
...
>>> class D(B, C): pass
...
>>> D.x
'c'
>>>
здесь, новый стиль, порядок:
>>> D.__mro__
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>,
<class '__main__.A'>, <type 'object'>)
с A
принудительно входит в порядок разрешений только один раз и после всех его подклассов, так что переопределения (т.е. переопределение C члена x
) действительно работают разумно.
Это одна из причин, по которой следует избегать классов старого стиля: множественное наследование с "алмазоподобными" шаблонами просто не работает с ними разумно, в то время как это происходит с новым стилем.
Ответ 2
Порядок разрешения метода Python на самом деле более сложный, чем просто понимание шаблона алмаза. Чтобы это понять, взгляните на линеаризацию C3. Я нашел, что это действительно помогает использовать заявления печати при расширении методов для отслеживания заказа. Например, что, по вашему мнению, будет результатом этого шаблона? (Примечание: "X" - это два пересекающихся края, а не node, а ^ означает методы, которые вызывают super())
class G():
def m(self):
print("G")
class F(G):
def m(self):
print("F")
super().m()
class E(G):
def m(self):
print("E")
super().m()
class D(G):
def m(self):
print("D")
super().m()
class C(E):
def m(self):
print("C")
super().m()
class B(D, E, F):
def m(self):
print("B")
super().m()
class A(B, C):
def m(self):
print("A")
super().m()
# A^
# / \
# B^ C^
# /| X
# D^ E^ F^
# \ | /
# G
Вы получили A B D C E F G?
x = A()
x.m()
После большой пробной ошибки я придумал неформальную интерпретацию теории графиса линеаризации C3 следующим образом: (Кто-то, пожалуйста, дайте мне знать, если это не так.)
Рассмотрим следующий пример:
class I(G):
def m(self):
print("I")
super().m()
class H():
def m(self):
print("H")
class G(H):
def m(self):
print("G")
super().m()
class F(H):
def m(self):
print("F")
super().m()
class E(H):
def m(self):
print("E")
super().m()
class D(F):
def m(self):
print("D")
super().m()
class C(E, F, G):
def m(self):
print("C")
super().m()
class B():
def m(self):
print("B")
super().m()
class A(B, C, D):
def m(self):
print("A")
super().m()
# Algorithm:
# 1. Build an inheritance graph such that the children point at the parents (you'll have to imagine the arrows are there) and
# keeping the correct left to right order. (I've marked methods that call super with ^)
# A^
# / | \
# / | \
# B^ C^ D^ I^
# / | \ / /
# / | X /
# / |/ \ /
# E^ F^ G^
# \ | /
# \ | /
# H
# (In this example, A is a child of B, so imagine an edge going FROM A TO B)
# 2. Remove all classes that aren't eventually inherited by A
# A^
# / | \
# / | \
# B^ C^ D^
# / | \ /
# / | X
# / |/ \
# E^ F^ G^
# \ | /
# \ | /
# H
# 3. For each level of the graph from bottom to top
# For each node in the level from right to left
# Remove all of the edges coming into the node except for the right-most one
# Remove all of the edges going out of the node except for the left-most one
# Level {H}
#
# A^
# / | \
# / | \
# B^ C^ D^
# / | \ /
# / | X
# / |/ \
# E^ F^ G^
# |
# |
# H
# Level {G F E}
#
# A^
# / | \
# / | \
# B^ C^ D^
# | \ /
# | X
# | | \
# E^F^ G^
# |
# |
# H
# Level {D C B}
#
# A^
# /| \
# / | \
# B^ C^ D^
# | |
# | |
# | |
# E^ F^ G^
# |
# |
# H
# Level {A}
#
# A^
# |
# |
# B^ C^ D^
# | |
# | |
# | |
# E^ F^ G^
# |
# |
# H
# The resolution order can now be determined by reading from top to bottom, left to right. A B C E D F G H
x = A()
x.m()
Ответ 3
Результат, который вы получите, верен. Попробуйте изменить базовый класс Base3
на Base1
и сравните его с той же иерархией для классических классов:
class Base1(object):
def amethod(self): print "Base1"
class Base2(Base1):
pass
class Base3(Base1):
def amethod(self): print "Base3"
class Derived(Base2,Base3):
pass
instance = Derived()
instance.amethod()
class Base1:
def amethod(self): print "Base1"
class Base2(Base1):
pass
class Base3(Base1):
def amethod(self): print "Base3"
class Derived(Base2,Base3):
pass
instance = Derived()
instance.amethod()
Теперь он выдает:
Base3
Base1
Подробнее читайте это объяснение.
Ответ 4
Вы видите это поведение, потому что разрешение метода имеет глубину - сначала, а не ширину. Dervied inheritance выглядит как
Base2 -> Base1
/
Derived - Base3
So instance.amethod()
- Проверяет Base2, не находит amethod.
- Видит, что Base2 унаследовал от Base1 и проверяет Base1. Base1 имеет
amethod
, поэтому он вызывается.
Это отражено в Derived.__mro__
. Просто перейдите по Derived.__mro__
и остановитесь, когда найдете искомый метод.