What Are Mixin Classes in Python?

Going Overboard With Mixins

Like every tool in software engineering, mixins are a double-edged sword. When used skillfully, they improve code reuse, separation of concerns, and maintainability, promoting an elegant, declarative style. At the same time, it’s easy to overdo them, leading to a poor design with diminishing returns in the long run.

If you’ve worked on enough Django projects, then chances are you’ve come across code that looks something like this:

# ...

class BookOverloadedView(
    LoginRequiredMixin,
    PermissionRequiredMixin,
    FormMixin,
    SingleObjectMixin,
    MultipleObjectMixin,
    FilterView,
    ExportMixin,
    AuditLogMixin,
    AjaxResponseMixin,
    OptimisticLockingMixin,
    UpdateView,
):
    model = Book
    form_class = BookForm
    permission_required = "library.change_book"
    filterset_class = BookFilter
    success_url = "/books/"

Spotting so many mixins in one place is a good indicator of a God object with too many responsibilities that would be better off refactored. For instance, you might decouple it by grouping related functionalities that are frequently used together into higher-level classes.

Including more than a few mixins at a time increases your code’s complexity, making it harder to understand and debug. Imagine trying to follow the flow of execution in this codebase, for example, to determine where a given method was implemented. Because of an extremely tangled inheritance hierarchy, that would be a non-trivial task.

Even worse, what if some of those mixins canceled each other out or stepped on each other’s toes? The observed behavior would depend on the order of their declaration, which is due to how method resolution works in Python. This brings you to another common risk associated with mixins, which you’ll look into now.

Ordering Mixins Incorrectly

Most mixins encapsulate orthogonal behaviors, meaning they operate independently and can typically be combined in any order. Occasionally, though, mixins may introduce conflicting implementations or rely on superclass methods being invoked in a specific sequence. This requires careful attention to their order in the inheritance list.

The two mixins you saw earlier, LoginRequiredMixin and PermissionRequiredMixin, are designed to work seamlessly together, no matter how you arrange them in the class definition. While both override the same .dispatch() method, they actively participate in cooperative multiple inheritance by calling Python’s super(). As a result, they form a chain of method calls to ensure that each mixin’s logic gets executed at some point.

Nevertheless, the official Django documentation recommends always including LoginRequiredMixin before any other mixins that could be triggered prematurely:

When using class-based views, you can achieve the same behavior as with login_required by using the LoginRequiredMixin. This mixin should be at the leftmost position in the inheritance list. (Source)

That sounds logical because Python follows base classes from left to right. After all, you’d want to check if the user has logged in before running any subsequent checks related to that user. Consider the following example, which violates this advice:

# ...

class BookDetailView(UserPassesTestMixin, LoginRequiredMixin, DetailView):
    model = Book

    def test_func(self):
        return self.request.user.email.endswith("@realpython.com")

Notice that LoginRequiredMixin appears second in the class declaration, just after UserPassesTestMixin. This mixin allows you to define a custom test that determines whether a user has permission to access the view. In this case, you verify that the user’s email address belongs to the @realpython.com domain.

The trouble with this code is that anonymous users in Django don’t come with an .email attribute. So, when an unauthenticated user tries to access this view, your test function will raise an AttributeError, resulting in an internal server error (HTTP 500) being displayed in the browser.

The preferred behavior would be to redirect unauthenticated users to the login page, giving them a chance to prove their identity before proceeding to the email domain check. You can achieve this goal by flipping the two mixin declarations in your view:

# ...

class BookDetailView(LoginRequiredMixin, UserPassesTestMixin, DetailView):
    model = Book

    def test_func(self):
        return self.request.user.email.endswith("@realpython.com")

Now, the web framework will ensure that the user is authenticated before checking their email address. In the worst-case scenario, after logging in, the user won’t have sufficient permissions to access the view and will receive a forbidden response (HTTP 403) that you can gracefully handle.

class TestMixin1(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.email.endswith("@example.com")

class TestMixin2(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.username.startswith("django")

class MyView(TestMixin1, TestMixin2, View): ...

Whenever your program’s behavior relies on implicit factors like the ordering of declarations, it makes your code fragile. Unfortunately, it’s an unavoidable aspect of multiple inheritance, which can manifest itself in even more nefarious ways. You’re about to explore a related gotcha of misplacing mixins in the class header.

Placing Mixins After Base Classes

Among the many challenges of using mixins, this is arguably the one that even seasoned Python developers fall victim to. Mixins should generally appear before other base classes in the inheritance list. Such ordering ensures that their methods are correctly invoked, either overriding or augmenting their counterparts in the base classes.

The only exception to this rule is when a mixin provides unique methods that are guaranteed not to conflict with those of other classes.

To illustrate this common mistake, imagine that you were to implement a data container for storing HTTP headers in Python. You may choose to create a custom case-insensitive mapping of key-value pairs—for example, by inheriting from UserDict as follows:

from collections import UserDict

class CaseInsensitiveDict(UserDict):
    def __setitem__(self, key: str, value: str) -> None:
        super().__setitem__(key.lower(), value)

    def __getitem__(self, key: str) -> str:
        return super().__getitem__(key.lower())

    def __delitem__(self, key: str) -> None:
        super().__delitem__(key.lower())

    def __contains__(self, key: str) -> bool:
        return super().__contains__(key.lower())

    def get(self, key: str, default: str = "") -> str:
        return super().get(key.lower(), default)

Your CaseInsensitiveDict overrides several special methods, which the parent class relies on internally, making sure that all keys are stored in lowercase form. That way, you can access and manipulate headers using any capitalization, such as "cookie" or "CooKIE":

>>> from utils import CaseInsensitiveDict

>>> headers = CaseInsensitiveDict()
>>> headers["Content-Type"] = "application/json"
>>> headers["Cookie"] = "csrftoken=a4f3c7d28c194e5b; sessionid=f92e4b7c6"

>>> headers["cookie"]
'csrftoken=a4f3c7d28c194e5b; sessionid=f92e4b7c6'

>>> "CooKIE" in headers
True

Now, say that you want to hook into some of these special methods through a mixin class that prints out useful debug messages:

from collections import UserDict

class DebugMixin:
    def __setitem__(self, key, value):
        super().__setitem__(key, value)
        print(f"Item set: {key=!r}, {value=!r}")

    def __delitem__(self, key):
        super().__delitem__(key)
        print(f"Item deleted: {key=!r}")

class CaseInsensitiveDict(UserDict, DebugMixin):
    # ...

The DebugMixin delegates execution to the corresponding superclass methods before printing messages whenever items in a collection are modified. To add this new behavior to your CaseInsensitiveDict, you append the mixin to the list of base classes in your class definition.

Unfortunately, after restarting the Python REPL and importing the updated utils module again, you won’t see any change in the observed behavior:

>>> from utils import CaseInsensitiveDict
>>> headers = CaseInsensitiveDict()
>>> headers["Content-Type"] = "application/json"
>>> headers["Cookie"] = "csrftoken=a4f3c7d28c194e5b; sessionid=f92e4b7c6"
>>> del headers["Cookie"]
>>> headers
{'content-type': 'application/json'}

The dictionary still lets you add and remove key-value pairs as expected, but none of the debug messages show up. That’s because the methods defined in your DebugMixin are never called. Python doesn’t invoke them since UserDict breaks the chain of delegation by not using super(). In other words, your mixin class is completely ignored.

You can follow the linearized inheritance chain of a class by inspecting its .__mro__ attribute. Here’s the MRO of your CaseInsensitiveDict:

>>> CaseInsensitiveDict.__mro__
(<class 'utils.CaseInsensitiveDict'>,
 <class 'collections.UserDict'>,
 <class 'collections.abc.MutableMapping'>,
 <class 'collections.abc.Mapping'>,
 <class 'collections.abc.Collection'>,
 <class 'collections.abc.Sized'>,
 <class 'collections.abc.Iterable'>,
 <class 'collections.abc.Container'>,
 <class 'utils.DebugMixin'>,
 <class 'object'>)

Because UserDict implements its methods without calling super(), it doesn’t delegate execution to the next ancestor, breaking the chain. At the same time, DebugMixin comes much later in the MRO, so its methods are effectively shadowed by those in UserDict. This means that even though DebugMixin appears in the inheritance chain, its functionality is bypassed.

The quickest fix would be to swap UserDict with DebugMixin in your class definition, as shown on the highlighted line below:

from collections import UserDict

class DebugMixin:
    # ...

class CaseInsensitiveDict(DebugMixin, UserDict):
    # ...

This moves DebugMixin to the top of the MRO, immediately after CaseInsensitiveDict and before UserDict. Consequently, the mixin’s methods will take precedence over the same methods defined in the subsequent ancestors:

>>> from utils import CaseInsensitiveDict

>>> CaseInsensitiveDict.__mro__
(<class 'utils.CaseInsensitiveDict'>,
 <class 'utils.DebugMixin'>,
 <class 'collections.UserDict'>,
 <class 'collections.abc.MutableMapping'>,
 <class 'collections.abc.Mapping'>,
 <class 'collections.abc.Collection'>,
 <class 'collections.abc.Sized'>,
 <class 'collections.abc.Iterable'>,
 <class 'collections.abc.Container'>,
 <class 'object'>)

Because your mixin class now delegates to super(), each time you add or delete a key-value pair, Python displays a descriptive message in addition to updating the dictionary:

>>> headers = CaseInsensitiveDict()

>>> headers["Content-Type"] = "application/json"
Item set: key='content-type', value='application/json'

>>> headers["Cookie"] = "csrftoken=a4f3c7d28c194e5b; sessionid=f92e4b7c6"
Item set: key='cookie', value='csrftoken=a4f3c7d28c194e5b; sessionid=f92e4b7c6'

>>> del headers["Cookie"]
Item deleted: key='cookie'

>>> headers
{'content-type': 'application/json'}

By strategically placing mixins within the inheritance chain and deciding whether to use the super() method, you gain control over behaviors defined in the ancestor classes. This powerful technique allows for implementing dependency injection without modifying the original class definitions.

At this point, you know that order matters when using multiple inheritance in Python—a common pattern with mixins. But there’s another important pitfall to be aware of when working with mixins that’s worth exploring.

Defining Uncooperative Constructors

Nine times out of ten, you should refrain from putting state into your mixin classes. Mixins are primarily concerned with providing behaviors rather than managing data. Once you start specifying instance attributes, you risk conflicts with attributes of the concrete classes they’ll be mixed with. And, since you typically define attributes in a custom initializer method, you now invite a host of problems associated with multiple inheritance.

To demonstrate what might go wrong when you store data in a mixin class, consider the following example. Suppose you want to restrict the type of keys in custom mappings to arbitrary data types. You may start by creating a parameterized mixin like this:

class TypedKeyMixin:
    def __init__(self, type_):
        self.type_ = type_

    def __setitem__(self, key, value):
        if not isinstance(key, self.type_):
            raise TypeError(f"key must be {self.type_} but was {type(key)}")
        super().__setitem__(key, value)

The mixin’s initializer method takes the desired key type as a parameter and stores it in an instance attribute named .type_. Additionally, the .__setitem__() method checks if the supplied key is an instance of the expected type, and then delegates to the superclass.

Now give your code a test drive by creating an inventory mapping where the keys are restricted to strings only:

>>> from collections import UserDict
>>> from mixins import TypedKeyMixin

>>> class Inventory(TypedKeyMixin, UserDict):
...     pass
...
>>> fruits = Inventory(str)
>>> fruits["apples"] = 42
Traceback (most recent call last):
  ...
AttributeError: 'Inventory' object has no attribute 'data'

Oops! You forgot to call super() in your initializer method, preventing other base classes from setting themselves up properly. Since your mixin class broke the inheritance chain, UserDict never created its .data attribute. Fortunately, there’s an easy fix for that:

class TypedKeyMixin:
    def __init__(self, type_):
        super().__init__()
        self.type_ = type_

    def __setitem__(self, key, value):
        if not isinstance(key, self.type_):
            raise TypeError(f"key must be {self.type_} but was {type(key)}")
        super().__setitem__(key, value)

By adding the call to super(), you ensure that Python triggers UserDict.__init__() at the right time. You can verify this by rerunning the same code snippet in the Python REPL:

>>> from collections import UserDict
>>> from mixins import TypedKeyMixin

>>> class Inventory(TypedKeyMixin, UserDict):
...     pass
...
>>> fruits = Inventory(str)
>>> fruits["apples"] = 42
>>> fruits["🍌".encode("utf-8")] = 15
Traceback (most recent call last):
  ...
TypeError: key must be <class 'str'> but was <class 'bytes'>

As expected, your inventory only accepts key-value pairs where the key is a string. If you attempt to use a key of any other data type, such as a bytes() object representing a banana emoji encoded in UTF-8, then Python will raise a TypeError.

At first glance, this solution seems rock solid. But as you start layering more behaviors through mixins that also rely on an internal state, things can get tricky.

Using Conflicting Instance Attributes

Encouraged by your progress so far, you decide to go ahead and create another mixin that restricts the type of associated values:

# ...

class TypedValueMixin:
    def __init__(self, type_):
        super().__init__()
        self.type_ = type_

    def __setitem__(self, key, value):
        if not isinstance(value, self.type_):
            raise TypeError(f"value must be {self.type_} but was {type(value)}")
        super().__setitem__(key, value)

The structure of TypedValueMixin is nearly identical to that of TypedKeyMixin, which you defined earlier. The primary distinction is that this mixin validates the type of the value parameter and emits a slightly different error message.

Sadly, when you include both mixins at the same time in your Inventory, you’re no longer able to instantiate it using two parameters corresponding to key and value types:

>>> from collections import UserDict
>>> from mixins import TypedKeyMixin, TypedValueMixin

>>> class Inventory(TypedKeyMixin, TypedValueMixin, UserDict):
...     pass
...
>>> fruits = Inventory(str, int)
Traceback (most recent call last):
  ...
TypeError: TypedKeyMixin.__init__() takes 2 positional arguments
⮑ but 3 were given

The error message is a bit misleading, as you need to subtract one from each number. Python expects only one explicitly passed positional argument, with the second one being the implicit self reference. In contrast, you’re passing two explicit arguments—str and int, for the keys and values—in addition to the implicit self.

The problem with your current implementation lies in how the mixin classes handle initialization. Although they correctly use super() to delegate control to their ancestors, they fail to forward the required arguments. To resolve this, you must update the method signatures and invocations of super() so that they can accept and pass through arbitrary arguments:

# ...

class TypedKeyMixin:
    def __init__(self, type_, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.type_ = type_

   # ...

class TypedValueMixin:
    def __init__(self, type_, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.type_ = type_

    # ...

To account for the fact that arguments in Python can be passed using either the positional or keyword syntax, you use *args and **kwargs to intercept both. Thanks to that, regardless of how you provide parameters to the constructor, they’ll be correctly received and dispatched.

This change lets you instantiate Inventory again. However, when you try to add a valid key-value pair, which previously worked fine, you get a rather puzzling complaint from Python:

>>> from collections import UserDict
>>> from mixins import TypedKeyMixin, TypedValueMixin

>>> class Inventory(TypedKeyMixin, TypedValueMixin, UserDict):
...     pass
...
>>> fruits = Inventory(str, int)
>>> fruits["apples"] = 42
Traceback (most recent call last):
  ...
TypeError: value must be <class 'str'> but was <class 'int'>

The error message insists that the value must be a string, even though you clearly declared it as an integer. It turns out that updating the signatures wasn’t enough. As you can see, dealing with bugs can sometimes feel like a game of whack-a-mole. You fix one problem, only to have another one pop up somewhere else!

Your mixins strip and forward values from the parameter lists correctly, but they both store the specified types in the same field (self.type_), which leads to a name collision. When you inspect your fruits inventory, you’ll notice there’s only one .type_ attribute:

>>> vars(fruits)
{'data': {},
 'type_': <class 'str'>}

Depending on how your mixins are ordered in the MRO, and whether you set the values before or after calling super(), one assignment effectively overwrites the other. In this case, int got replaced by str. This makes distinguishing between the types intended for keys and values impossible.

To avoid ambiguity, it’s best to stick to unique names, or better yet, rely on Python’s name mangling by prefixing attribute names with a double underscore (__). Also, while not mandatory, choosing more descriptive names like key_type and value_type for your parameters will definitely improve readability:

# ...

class TypedKeyMixin:
    def __init__(self, key_type, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.__type = key_type

    def __setitem__(self, key, value):
        if not isinstance(key, self.__type):
            raise TypeError(
                f"key must be {self.__type} but was {type(key)}"
            )
        super().__setitem__(key, value)

class TypedValueMixin:
    def __init__(self, value_type, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.__type = value_type

    def __setitem__(self, key, value):
        if not isinstance(value, self.__type):
            raise TypeError(
                f"value must be {self.__type} but was {type(value)}"
            )
        super().__setitem__(key, value)

This makes Python rename both of your .__type attributes behind the scenes, resulting in two distinct identifiers visible from the outside:

>>> vars(fruits)
{'data': {},
 '_TypedValueMixin__type': <class 'int'>,
 '_TypedKeyMixin__type': <class 'str'>}

The nice thing about name mangling is that you can still access these attributes directly using their original names, like .__type, from within their respective classes.

Putting it all together, your stateful mixins finally work as they should:

>>> fruits = Inventory(str, int)
>>> fruits["apples"] = 42
>>> fruits["🍌".encode("utf-8")] = 15
Traceback (most recent call last):
  ...
TypeError: key must be <class 'str'> but was <class 'bytes'>
>>> fruits["bananas"] = 3.5
Traceback (most recent call last):
  ...
TypeError: value must be <class 'int'> but was <class 'float'>

Trying to use key or value types other than those declared in the constructor immediately raises exceptions, keeping your inventory in a consistent state.

Now that you know what to avoid when implementing custom mixins in Python, it’s time to break the rules! Next up, you’ll consciously design stateful mixins that can be safely integrated into other classes.

Move the State to Class Attributes

You can minimize the hurdles of multiple inheritance by taking a different route. Simply eliminate the initializer methods and replace instance attributes with class attributes, like so:

class TypedKeyMixin:
    key_type = object

    def __setitem__(self, key, value):
        if not isinstance(key, self.key_type):
            raise TypeError(
                f"key must be {self.key_type} but was {type(key)}"
            )
        super().__setitem__(key, value)

class TypedValueMixin:
    value_type = object

    def __setitem__(self, key, value):
        if not isinstance(value, self.value_type):
            raise TypeError(
                f"value must be {self.value_type} but was {type(value)}"
            )
        super().__setitem__(key, value)

This moves the state from the individual instances—accessed with self—to the target class. If a class composed of your mixins doesn’t specify these attributes, then Python will fall back to their default values defined in the corresponding mixin classes. In this case, both attributes default to object.

In turn, you’ll be able to use a declarative style resembling that of the Django mixins you saw earlier to specify your key and value types:

>>> from collections import UserDict
>>> from stateful_v1 import TypedKeyMixin, TypedValueMixin

>>> class Inventory(TypedKeyMixin, TypedValueMixin, UserDict):
...     key_type = str
...     value_type = int
...

>>> fruits = Inventory()

>>> fruits["apples"] = 42

>>> fruits["🍌".encode("utf-8")] = 15
Traceback (most recent call last):
  ...
TypeError: key must be <class 'str'> but was <class 'bytes'>

>>> fruits["bananas"] = 3.5
Traceback (most recent call last):
  ...
TypeError: value must be <class 'int'> but was <class 'float'>

>>> vars(fruits)
{'data': {'apples': 42}}

The key_type and value_type attributes aren’t part of the fruits instance, as confirmed by vars(), so they won’t interfere with the internal state of other base classes. However, they can still shadow class attributes with the same names.

Although a collision of class attributes is far less likely to happen, you may want to safeguard against it anyway. To make your code immune to such name clashes, consider using a closure.

Hide the State in Function Closures

There’s a more elegant way to create stateful mixins, which is free from the aforementioned problems. Rather than have generic, parameterized mixin classes, you can dynamically synthesize their concrete variants as needed with the help of Python closures:

def TypedKeyMixin(key_type=object):
    class _:
        def __setitem__(self, key, value):
            if not isinstance(key, key_type):
                raise TypeError(
                    f"key must be {key_type} but was {type(key)}"
                )
            super().__setitem__(key, value)
    return _

def TypedValueMixin(value_type=object):
    class _:
        def __setitem__(self, key, value):
            if not isinstance(value, value_type):
                raise TypeError(
                    f"value must be {value_type} but was {type(value)}"
                )
            super().__setitem__(key, value)
    return _

By wrapping class definitions in higher-order factory functions, you create specialized mixins tailored to the supplied parameter. Because this parameter is bound to the function’s lexical scope, each mixin retains its own distinct value without leaking it into others. This prevents unintended sharing of state or cross-contamination between your mixin variants.

Now, here’s how you might use your new mixins in practice:

>>> from collections import UserDict
>>> from stateful_v2 import TypedKeyMixin, TypedValueMixin

>>> class Inventory(TypedKeyMixin(str), TypedValueMixin(int), UserDict):
...     key_type = "This attribute has nothing to collide with"
...

>>> fruits = Inventory()

>>> fruits["apples"] = 42

>>> fruits["🍌".encode("utf-8")] = 15
Traceback (most recent call last):
  ...
TypeError: key must be <class 'str'> but was <class 'bytes'>

>>> fruits["bananas"] = 3.5
Traceback (most recent call last):
  ...
TypeError: value must be <class 'int'> but was <class 'float'>

>>> vars(fruits)
{'data': {'apples': 42}}

>>> Inventory.key_type
'This attribute has nothing to collide with'

Notice how you call the closures with their respective arguments in the class definition. This dynamically creates new mixins on the spot.

Because the state is encapsulated within the closures rather than stored in the mixins, the target class avoids inheriting potentially conflicting attributes. Additionally, since the mixins don’t define any class attributes of their own, there’s no risk of name collisions at the class level either.

Finally, you can use composition as an alternative to mixins to sidestep multiple inheritance. In the next section, you’ll explore how that works.

Compose Behaviors With Decorators

If this tutorial has left you unconvinced about using mixins, then Python offers several other tools for composing behaviors and promoting code reuse. In particular, decorators provide a flexible and readable way to extend functionality without the complexity of multiple inheritance.

You can adapt your mixin classes by turning them into class decorators that augment the .__setitem__() method:

def key_type(expected_type):
    def class_decorator(cls):
        setitem = cls.__setitem__

        def __setitem__(self, key, value):
            if not isinstance(key, expected_type):
                raise TypeError(
                    f"key must be {expected_type} but was {type(key)}"
                )
            return setitem(self, key, value)

        cls.__setitem__ = __setitem__
        return cls

    return class_decorator

def value_type(expected_type):
    def class_decorator(cls):
        setitem = cls.__setitem__

        def __setitem__(self, key, value):
            if not isinstance(value, expected_type):
                raise TypeError(
                    f"value must be {expected_type} but was {type(value)}"
                )
            return setitem(self, key, value)

        cls.__setitem__ = __setitem__
        return cls

    return class_decorator

These two decorators, @key_type and @value_type, inject new behaviors into a class by replacing its .__setitem__() method. Each decorator checks whether the key or value passed into the dictionary is of the expected type, raising a TypeError if not.

You can put these decorators into action by stacking them on top of a UserDict subclass:

>>> from collections import UserDict
>>> from stateful_v3 import key_type, value_type

>>> @key_type(str)
... @value_type(int)
... class Inventory(UserDict):
...     key_type = "This attribute has nothing to collide with"
...
>>> fruits = Inventory()

>>> fruits["apples"] = 42

>>> fruits["🍌".encode("utf-8")] = 15
Traceback (most recent call last):
  ...
TypeError: key must be <class 'str'> but was <class 'bytes'>

>>> fruits["bananas"] = 3.5
Traceback (most recent call last):
  ...
TypeError: value must be <class 'int'> but was <class 'float'>

>>> vars(fruits)
{'data': {'apples': 42}}

>>> Inventory.key_type
'This attribute has nothing to collide with'

This example works the same as the previous one based on mixin classes. Although the order of decorators generally matters—just like ordering mixins—it has no visible effect in this particular case. This is due to the non-overlapping nature of the encapsulated behaviors.

If you’re feeling adventurous, then why not combine both decorators into a single one so you can apply it in one step? For example:

# Enforce str keys and int values:
@typed_dict(str, int)
class Inventory(UserDict):
    pass

# Enforce str keys, allow any value type:
@typed_dict(str)
class AppSettings(UserDict):
    pass

Give it a try yourself first, and then compare your solution to the one below:

def typed_dict(key_type=object, value_type=object):
    def class_decorator(cls):
        setitem = cls.__setitem__

        def __setitem__(self, key, value):
            if not isinstance(key, key_type):
                raise TypeError(
                    f"value must be {key_type} but was {type(key)}"
                )

            if not isinstance(value, value_type):
                raise TypeError(
                    f"value must be {value_type} but was {type(value)}"
                )

            setitem(self, key, value)

        cls.__setitem__ = __setitem__

        return cls

    return class_decorator

By using decorators, you gain explicit control, better testability, and improved separation of concerns compared to traditional mixins. This approach avoids method resolution traps and enables safer runtime customization.

On the one hand, decorators may be more verbose, but they offer a powerful and maintainable alternative to mixins when inheritance is either impractical or undesirable.