A mixin is a small class that adds one focused capability to other classes through multiple inheritance. Mixins don't make sense as standalone objects; they're meant to be combined with a "real" class that has the domain data and behavior. The chapter on multiple inheritance introduced the idea briefly. This one covers the pattern itself: what makes a class a mixin (rather than a regular base), how to design one well, where mixins fit alongside composition and decorators, and how the standard library and Django use them at scale.

A mixin is a class designed to be inherited from, not instantiated. Writing DiscountableMixin() wouldn't produce a useful object. The class becomes useful only when combined with another class that has the state the mixin's methods need.

Compare two versions of the same idea. First, a regular base class:

Product is a complete, useful class on its own. It has its own state (name, price) and a method that uses that state. It can be instantiated directly and produce something sensible.

Now the mixin version:

DiscountableMixin doesn't have state. It doesn't have an __init__. It has one method, and that method references self.price, which the mixin itself doesn't define. Instantiating DiscountableMixin() directly would create a useless object: it has no price, so apply_discount would raise AttributeError on the first call. The class becomes useful only when combined with something that has a price.

That's the shape of a mixin: it adds a capability that depends on attributes another class provides. The dependency is what makes the class a mixin rather than a regular base. A regular base owns its state. A mixin borrows state from the class it gets mixed into.

The diagram shows the typical mixin shape. Product is the domain class with the state. DiscountableMixin and ShippableMixin are mixins that contribute behavior using that state. Laptop combines all three to produce a class with the state, the discount logic, and the shipping logic. Nothing in this picture is reusable on its own except Product; the mixins exist for the combination.

The Python community has settled on two naming styles for mixins. Use the one that reads better for the capability being added:

Either style works. The community is split. Frameworks like Django mostly use the Mixin suffix; some libraries favor -able. Both styles avoid naming mixins like domain nouns. A class called Discount (with no suffix) reads like a real entity, and a future reader will wonder why Laptop "is a" Discount. The naming pattern is part of how mixins document themselves.

Names to avoid:

The naming carries information. When a reader sees class Laptop(Product, DiscountableMixin, ShippableMixin):, the parent list says what's going on without their needing to read the bodies: Laptop is a Product, with discount and shipping capabilities mixed in. If the parents were named Product, Discount, Shipping, the reader would have to look up each class to figure out which are domain types and which are behaviors.

Mixins work best when they follow a small set of conventions. None are enforced by Python; all of them make mixins predictable and easy to combine.

Keep the mixin focused on one capability. A mixin called LoggableMixin should add logging and nothing else. If it also adds caching and serialization, it bundles three unrelated concerns into one class, and anyone who needs only logging is forced to take all three. Small, single-purpose mixins compose cleanly; fat mixins fight each other when combined.

Avoid state where possible. The cleanest mixins have no __init__ of their own. They define methods that operate on attributes the host class provides, and they leave the storage and lifecycle to the host. When a mixin really needs its own state (a per-instance list, a counter), make sure its __init__ is cooperative: it accepts *args, **kwargs, calls super().__init__(*args, **kwargs), and then sets only its own attributes. The chapter on multiple inheritance covered cooperative super() in detail; the same rules apply to mixin __init__ methods.

Document the contract. A mixin's methods refer to attributes the host must provide. Spell out which ones in the class docstring or near the method:

The docstring tells a future reader what TaxableMixin assumes. Without it, the reader has to scan every method to find the self.x references. With it, the dependency is documented in one place.

Mind the method resolution order. Writing class Laptop(Product, DiscountableMixin, ShippableMixin): lets the parent order determine which class wins for overlapping method names. The convention is to list the "real" base class first and the mixins after, so mixin overrides take precedence over the base. If two mixins both define a describe method, the one listed first wins. Reordering parents repeatedly to make a test pass usually means the design is trying to combine mixins with overlapping responsibilities, which is a sign to split them or rethink the hierarchy.

The diagram traces what the parent order means at runtime. Python computes the MRO once when the class is created, and method lookups walk that fixed list. With the listed order, Laptop finds attributes on Product before either mixin, which gives the base class precedence; the mixins fill in additional methods the base doesn't have.

A more complete picture: a Product class provides the state. Three mixins add unrelated capabilities. A specific product subclass combines what it needs:

Book doesn't define any methods of its own. It composes capabilities from four parents: storage (Product), tax (TaxableMixin), gift wrap (GiftWrappableMixin), and reviews (ReviewableMixin). A DigitalBook that's reviewable and taxable but doesn't ship physically would list a different set of parents. Adding a FeaturedMixin that bumps the price in search rankings is a one-time write that can be used anywhere a product needs it.

The parent order matters. ReviewableMixin is listed first because its __init__ cooperates with super() and needs to be entered first so the chain reaches Product.__init__. TaxableMixin and GiftWrappableMixin have no __init__, so their position relative to Product doesn't affect initialization, but listing them before Product lets them override any same-named methods if they ever needed to. The convention is mixins first, base class last; the reverse order also works for many cases but is harder to reason about when __init__ chaining matters.

Each mixin adds one entry to the MRO and one Python call per super() step in the __init__ chain. For typical mixin stacks of two to four classes, the overhead is in the microsecond range and irrelevant to almost any application. A stack of ten mixins on one class is a sign to reconsider the design before measuring.

A common worry: what if two mixins define methods with the same name? The MRO resolves it deterministically (first parent listed wins), but the silent override is a debugging trap. The discipline is to keep mixin method names unique within a project, or to be explicit about cooperative overrides using super(). Plain method collisions between unrelated mixins are almost always a design problem.

Most mixins have no __init__ at all. They contribute methods, and the host class is responsible for the constructor. When a mixin really does need its own state, the constructor has to cooperate with the rest of the chain so the host's __init__ and any other mixin __init__ methods still run.

The pattern is the one from the multiple inheritance chapter:

Each __init__ peels off the keyword arguments it cares about (with keyword-only syntax via *) and forwards the rest through **kwargs. The call eventually reaches object.__init__, which expects no extra arguments, so every keyword has to be consumed by the time the chain finishes. A missing super().__init__(**kwargs) anywhere means the classes below that point in the MRO never have their __init__ run, and their attributes never get set.

The decision of whether to give a mixin its own state isn't always obvious. A few questions help:

The general rule: mixins lean stateless. When state is necessary, keep it tightly scoped to the capability and use cooperative super() to play well with the rest of the chain.

A mixin is one way to add capability. Two others are common in Python: composition (the host class holds an instance of a helper) and decorators (a function that wraps another callable). The three approaches solve overlapping problems, and choosing well depends on the shape of the dependency.

Composition: hold a helper as an attribute.

The product holds a TaxCalculator instance and delegates the work to it. The capability is reusable across any class that wants to instantiate one. The price is one extra dot at the call site (mouse.tax.with_tax(...) instead of mouse.price_with_tax()), which sometimes is the desired form (it makes the dependency explicit) and sometimes is heavier than necessary.

Decorator: wrap a function or method.

The decorator wraps a single method without touching the class hierarchy. The capability (logging) lives in the decorator and can be applied to methods on any class. No inheritance, no MRO, no parent ordering. The trade-off is that decorators add capability to individual methods, not to the class as a whole, so reusing the same behavior across many methods requires decorating each one.

When does each approach fit? A rough guide:

Both composition and mixins solve the same kinds of problems. The choice often comes down to taste and to how tightly the capability is bound to the host's data. Mixins are more compact (no extra dot at the call site) but coupled (the host must include them in the parent list and inherit their MRO). Composition is more verbose at use sites but decouples the helper from the host. Many projects mix both freely; consistency within a codebase helps readers know which pattern to expect.

A specific anti-pattern: don't use a mixin when composition would do, and vice versa. If TaxCalculator has its own state, its own lifecycle, and could be swapped at runtime (a regular TaxCalculator for some customers, a EuropeTaxCalculator for others), it's a separate object. Composing it as an attribute makes that swap easy. Inheriting it as a mixin would freeze the choice at class-definition time. Conversely, if DiscountableMixin is one method that uses self.price and never needs its own state, composing it as an attribute is overkill; the mixin reads more cleanly.

Mixins aren't a niche pattern. Two pieces of Python lean heavily on them: the standard library's collections.abc module and Django's class-based views.

`collections.abc` provides abstract base classes that act as mixins for container types. Inheriting from collections.abc.MutableSequence and providing implementations of __getitem__, __setitem__, __delitem__, __len__, and insert gives access to append, extend, pop, remove, __iter__, __contains__, index, count, reverse, and __iadd__ through inheritance, all built on top of the methods provided. The pattern is the one described above: the mixin's methods use the abstract methods as their building blocks, and the mixin contributes a useful surface that depends on those building blocks.

The WishList class implements five core methods. MutableSequence provides everything else: iteration, append, remove, __contains__, and the rest. That's a lot of behavior for a small amount of code, all built on the mixin pattern. MutableSequence doesn't define _items; the host class does. The mixin's methods use the abstract operations (__getitem__, insert, and so on) to do their work.

Django's class-based views take the pattern further. A typical Django view inherits from several mixins, each contributing one piece of the request handling:

LoginRequiredMixin adds the check that the user is authenticated. PermissionRequiredMixin adds the check that the user has the right permission. DetailView is the actual view (the domain class) that retrieves a single object and renders a template. Each mixin overrides dispatch (or one of its helpers) with super() calls so the chain cooperates: the login check runs, then the permission check, then the actual view logic. Combining them by listing them in the parent class declaration is the pattern described above.

What matters in these examples isn't the specific class names. It's the idea that mixins scale to real frameworks. The same rules apply at any scale: one capability per mixin, document the contract, cooperate with super(), list mixins in MRO order with the domain class last. The Python standard library and Django both bet on the pattern because it lets a small number of well-designed mixins combine into a large number of useful classes.

Mixins are a clean tool when the parents are orthogonal (unrelated axes of behavior) and the host class needs to compose several independent capabilities. They become a mess when the parents fight each other or when the dependency model gets tangled.

Avoid mixins when:

The rule: use a mixin for a small, focused capability that several classes will need independently, when the capability depends naturally on attributes the host class will provide. Use composition when the capability is its own object. Use a decorator when the behavior is at the call boundary. When in doubt, composition is usually the safer default; it doesn't introduce inheritance complexity, and it makes the dependency explicit at construction time.