PCAP Object-Oriented Programming Practice Question

Exhibit

class A:
    def method(self):
        return "A"

class B(A):
    def method(self):
        return "B"

class C(A):
    def method(self):
        return "C"

class D(B, C):
    pass

print(D.__mro__)

Refer to the exhibit. What is the output? (Note: actual MRO may vary; choose the one that matches Python 3 C3 linearization.)

⚠ Common exam trap

Python Institute often tests whether candidates remember that `object` is always the last class in the MRO for new-style classes in Python 3, and that the local precedence order of base classes (left-to-right in the class definition) must be strictly followed in the linearization.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

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

Python 3 uses C3 linearization to compute the Method Resolution Order (MRO). For class D inheriting from B and C, which both inherit from A, the MRO is D, B, C, A, object. This satisfies the monotonicity and local precedence order: B comes before C (as per D's bases), and A is last among the user-defined classes, with object always appended.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>)
Why it's wrong here
This tuple omits object, the universal root of Python's new-style class hierarchy. C3 linearization always appends object as the final class, because every class ultimately inherits from it even when no explicit base is written. Removing object would leave the MRO without the required common-superclass fallback for special methods like __repr__ and __eq__, so this cannot be what D.__mro__ actually returns.
✓
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
Why this is correct
This is the exact tuple produced by C3 linearization for class D(B, C), where both B and C inherit from A. The merge step selects B first because it is the declared first base of D and is not a tail of any other candidate list; it then selects C, followed by A, and finally object. This order respects both the local precedence D(B, C) and the monotonicity rule that the MROs of B and C remain prefixes of D's MRO.
✗
(<class '__main__.D'>, <class '__main__.C'>, <class '__main__.B'>, <class '__main__.A'>, <class 'object'>)
Why it's wrong here
C3 linearization must preserve the order in which base classes are written in the class statement: since D is defined as D(B, C), B must precede C in D's MRO. This option reverses that declaration order, which is what you would expect for D(C, B), not for the actual source code. It also wrongly places C's entire branch ahead of B's branch, directly contradicting the explicit base-class order.
✗
(<class '__main__.D'>, <class '__main__.A'>, <class '__main__.B'>, <class '__main__.C'>, <class 'object'>)
Why it's wrong here
This order places A ahead of B and C even though A is only an indirect ancestor of D. In C3, a class must always be listed after its direct bases, and the direct bases of D—B and C—must appear in their declared order before any common ancestor like A is considered. This is a depth-first-style guess that puts the shared ancestor first, violating the local precedence constraint that C3 enforces and breaking the expected super() resolution path.

Go deeper

PCAP Object-Oriented Programming Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question