Mixin classes are the kind of Python feature that experienced developers use without thinking, then stumble on when they have to explain them. The pattern is small, but the pitfalls hit hard: misuse of super(), confusion with abstract base classes, and method resolution order (MRO) surprises that only show up in production when an unrelated parent class suddenly wins a method lookup.
Real Python published a 10-question quiz that targets exactly these gaps. I worked through it, and I want to walk through what it actually tests, where it caught me off-guard, and how to use the quiz as a self-check before you reach for a mixin in your next code review.
This is a writeup of the experience, not a cheat sheet. The questions are open to anyone with a free Real Python account. If you have not yet taken the quiz, give it a real try first; the points below will land harder if you have skin in the game.
What the quiz actually tests
Ten questions across three skills. Recognition first: the first block checks whether you can spot a mixin from a class definition. The pattern mixins follow is small, a class that does not stand on its own, exposes a few methods, and is meant to be combined with others through multiple inheritance. If you have written a class that adds to_dict(), to_json(), or from_dict() to a domain model, you have written a mixin. The quiz asks you to identify this pattern in code that looks similar but is not always a mixin (some examples are abstract base classes, some are just utility classes).
MRO is the second block. The method resolution order (the sequence Python uses to look up an attribute when multiple parent classes define it) matters more than most tutorials admit. C3 linearization (the deterministic ordering Python uses to combine multiple inheritance chains) is what determines which method wins, and the quiz tests whether you can predict the order without running the code. This is the section where most experienced developers discover a gap; they have used mixins for years but always relied on trial-and-error instead of predicting the order.
Stateful mixins close out the quiz. These add instance attributes to the combined class, which raises a real question: where does the attribute live, and what happens when two mixins try to define the same attribute? The quiz walks you through these conflicts with code snippets and asks which value wins. The expected answer is not always the obvious one.
Questions that distinguished signal from noise
Three questions stood out as the strongest signal of real understanding.
The first showed a base class that called super().__init__() and a mixin that also called super().__init__(). Asking the obvious question: does the mixin’s super() chain reach the base class, and in what order? Most answers reason about MRO and forget that super() only follows the MRO chain defined by the next class in the order. If the mixin is listed first, its super() call goes to the base class. If the mixin is listed second, its super() call goes to whatever is next in the MRO. The order matters.
Number two asked whether you can put a mixin in a class that does not define the methods the mixin requires. Yes, and that is the whole point of a mixin: it makes assumptions about the class it is mixed into, and the developer is responsible for ensuring those assumptions hold. The quiz forces you to spot the assumption and reason about what happens when it breaks.
Third test was a real production bug shape: a mixin that defines a property (a Python attribute accessed like a field but computed by a method under the hood) and a base class that defines the same name as a regular attribute. Which wins? The answer depends on the class hierarchy and the order of attributes, but the trap is that the property only works for instances that go through the mixin. If you instantiate the base class directly, the property is missing. This is the kind of subtle bug that does not show up in unit tests because the test fixture always uses the mixin.
My three weakest moments
I missed two questions on the first pass. Both were about MRO.
My first miss was about a diamond inheritance shape (a four-class hierarchy where one class inherits from two others that share a common ancestor). Diamond is the classic MRO stress test, and my answer was off by one position because I forgot that Python’s C3 linearization flattens the hierarchy in a specific way. The right way to think about it is to walk the MRO list step by step, not to try to reason about it abstractly.
Question two dealt with a stateful mixin that defined __init__ and a base class that also defined __init__. The mixin’s __init__ overrode the base class’s entirely unless I called super().__init__(). The question was whether the base class’s __init__ still ran. The answer is no, not unless the mixin explicitly chains it. This is the kind of thing that gets caught in code review but not in unit tests.
Close call number three asked about a mixin that depended on a class attribute (a variable defined on the class itself, shared across all instances) defined in the base class. The mixin worked, but the base class did not have the attribute. Asking whether the mixin would raise an error at class definition time or at instance creation. Answer: at instance creation, because Python only resolves attributes when you access them. Subtle point about when Python checks types and when it does not.
How to use the quiz as a self-check
Quick on the time budget. Ten questions, no time limit, takes about 15 minutes if you read the code snippets carefully. The free tier on Real Python gives you the score at the end and a breakdown of which topics you missed. The paid tier adds the full explanations and links to the relevant tutorial sections.
If you want to use it as a real diagnostic, this is the workflow:
- Take the quiz cold, score yourself, write down the question numbers you missed.
- Read the explanations for every question you got wrong plus every question you got right but guessed on.
- Open a project you actually maintain and leave a comment on the file where the gap showed up.
- Take the quiz again in two weeks. The second pass is where you find out whether the lessons stuck.
Ten questions is the right size. Five would not have covered the MRO depth. Twenty would have padded the quiz with marginal cases. Every question in this set tests a specific skill.
Trade-offs
The quiz is a quiz, not a tutorial. It tests recognition, not deep understanding. If you get a question right by elimination, you have not learned the underlying concept; you have just learned the test format. The free tier gives you the answers, but the explanations are short. The paid tier adds context, but you still have to do the work of connecting the explanations to your own code.
MRO questions are the real test. Pattern-recognition questions are easy for anyone who has read a mixin tutorial. Stateful mixin questions are medium. MRO questions are where you find out whether you have actually internalized how Python composes classes or whether you have just memorized the happy-path examples. If you score 100% on the recognition questions and miss 50% of the MRO questions, you have a real gap to address.
The quiz format also misses the design question. When should you reach for a mixin, and when should you reach for composition (passing the helper object as a constructor argument instead of inheriting from it)? The quiz does not ask this. It assumes you already know when to use a mixin and just want to test whether you can use one correctly. Fine scope, but it leaves the harder question for a separate read.
Bottom line
If you write Python with classes and you have not thought about MRO in the last six months, take the quiz. The 15 minutes will surface at least one gap you did not know you had. If you already teach mixins to others, the quiz is still worth a pass for the question phrasing; some of the distractors are sharp enough to steal from for your own materials.
The single most useful thing I took from the quiz was the reminder that mixin behavior depends on the order of the class list in the class definition, not on the order of the methods inside the mixin. If you have not read the C3 linearization algorithm recently, the quiz is a good reason to do it now. The algorithm is short, the explanation on the Python documentation site is clear, and the cost of not knowing it is real production bugs.