Challenge 2: Trace the MRO — Possible Solution
====================================================================

class A:
    pass

class B(A):
    pass

class C(A):
    pass

class D(B, C):
    pass

print(D.__mro__)

# A appears only once because Python's C3 linearization algorithm
# merges each class's ancestor chain while preserving each class's
# own local ordering, guaranteeing every class appears exactly once
# in the final result regardless of how many paths lead to it.

Output:
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)

WHY THIS WORKS AS AN ANSWER
------------------------------
This is a direct diamond-shaped hierarchy: D inherits from both B and
C, and both B and C independently inherit from the same class, A —
structurally the exact "two parents share a common grandparent" shape
the chapter's warn-box names as the classic diamond problem.

print(D.__mro__) reuses this chapter's own Duck.__mro__ example
exactly, applied to a hierarchy with an actual shared ancestor instead
of two unrelated parents. The printed order — D, B, C, A, object —
follows the same left-to-right-through-each-parent rule demonstrated
with Flyer/Swimmer: D itself first, then B (listed first in
class D(B, C)), then C, then their shared parent A, then Python's
universal base object.

The reason A appears only ONCE despite being an ancestor via both B
and C is exactly what the chapter's own explanation of the MRO
promises: the C3 linearization algorithm computes one single,
deterministic order for the whole hierarchy, rather than naively
walking each parent's chain independently (which would visit A twice
— once through B, once through C). This guarantee is precisely why
the MRO can resolve the diamond problem deterministically instead of
leaving it ambiguous.