Using Mix-ins with Python

An explanation of the mix-in programming style as applied in Python.
Advanced Versions of MixIn( )

The first enhancement we can add to MixIn( ) is to check that we're not mixing in the same class twice:

def MixIn(pyClass, mixInClass):
    if mixInClass not in pyClass.__bases__
        pyClass.__bases__ += (mixInClass,)

In practice, I find more often than not, that I want my mix-in methods to take a high priority, even superseding inherited methods if needed. The next version of the function puts the mix-in class at the front of the sequence of base classes but allows you to override this behavior with an optional argument:

def MixIn(pyClass, mixInClass, makeLast=0):
  if mixInClass not in pyClass.__bases__
    if makeLast:
      pyClass.__bases__ += (mixInClass,)
      pyClass.__bases__ = (mixInClass,) + pyClass.__bases__
To make Python invocations more readable, I suggest using keyword arguments for flags:
# not so readable:
MixIn(Story, StoryInterface, 1)
# much better:
MixIn(Story, StoryInterface, makeLast=1)
Listing 4. Our Final Version of MixIn

This new version still doesn't allow methods in the actual class to be overridden with methods in the mix-in. In order to accomplish that, the mix-in methods must actually be installed in the class. Fortunately, Python is dynamic enough to accomplish this. Listing 4 gives the source code for our final version of MixIn( ). By default it will install the methods of the mix-in directly into the target class, even taking care to traverse the base classes of the mix-in. The invocation is the same:

MixIn(Story, StoryInterface)

An extra makeAncestor=1 argument can be provided for the new MixIn( ) to get the old semantics (e.g., make the mix-in a base class of the target class). The ability to put the mix-in at the end of the base classes has been removed, since I have never needed this in practice.

An even more sophisticated version of this function could return (perhaps optionally) a list of methods that clash between the two, or raise an exception accompanied by such a list, if the overlap exists.

Installing Mix-ins Automatically

When making heavy use of after-the-fact mix-ins, invocations of the MixIn( ) function become repetitious. For example, a GUI application might have a mix-in for every domain class in existence, thereby requiring a call such as this for each one:

from Domain.User import User
MixIn(User, UserMixIn)

One solution is to bind the mix-ins to their target classes by name and have the application install these at startup. For example, all mix-ins could be named directly after the class they modify and put into a MixIns/ directory. The code in Listing 5 will install them.

Listing 5. Detecting and Installing Mix-ins Named after Their Classes

Additional Uses

While it's fun to explore more sophisticated versions of the MixIn( ) function, the most important key is the ability to apply them in order to improve your software. Here are some additional uses to stimulate your imagination:

  • A class could augment itself with a mix-in after reading a configuration file. For example, a web server class could mix in Threading or Forking depending on how it's configured.

  • A program could provide for plug-ins: software packages that are located and loaded at launch time to enhance the program. Those who implement plug-ins could make use of MixIn( ) to enhance core program classes.


Mix-ins are great for improving modularity and enhancing existing classes without having to get intimate with their source code. This in turn supports other design paradigms, like separation of domain and interface, dynamic configuration and plug-ins. Python's inherent support for multiple inheritance, dynamic binding and dynamic changes to classes enables a very powerful technique. As you continue to write Python code, consider ways in which mix-ins can enhance your software.

Chuck Esterbrook is a consultant, writer and entrepreneur, using Python ( and Webware ( He can be reached at



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Just can't stand seeing this

Grubert's picture

Just can't stand seeing this Mixin() function. It's a prime example of pointless code; all it does is call a function on the object passed in.

"In case we want to add to it.." and what might you add to such a generic operation?

If you're going to write that kind of thing, use Java. Those guys expect it.

And mixins make more sense in a language like Java, where interface implementations must be complete. Python's duck typing means you only need as much implementation as you need, and on top of that there's no reason to not just make a runtime object with the necessary method rather then adding methods to an existing object.

Much abo about very little.

"Python supports dynamic changes to the class hierarchy."

Donny Viszneki's picture

CPython supports this, but that isn't necessarily the same as saying Python supports this. You can't just set some __class__ member variable in Jython or IronPython, for example. Tinypy also supports this sort of thing, but with more Lua-esque "metatables."