Using Mix-ins with Python
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,) else: 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:
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.
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.
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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
5 hours 16 min ago
- BASH script to log IPs on public web server
9 hours 43 min ago
13 hours 19 min ago
- Reply to comment | Linux Journal
13 hours 51 min ago
- All the articles you talked
16 hours 15 min ago
- All the articles you talked
16 hours 18 min ago
- All the articles you talked
16 hours 19 min ago
20 hours 44 min ago
- Keeping track of IP address
22 hours 35 min ago
- Roll your own dynamic dns
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?