Question

I am working on a Django application but this seems like it is just a python question, with nothing necessarily specific to Django. I’m pretty new to python, and its hard to describe what I am trying to do, but easier to show so here goes:

I have one class:

class SlideForm(ModelForm):

    class Meta:
        model = Slide

which I subclass:

class HiddenSlideForm(SlideForm):
    def __init__(self, *args, **kwargs):
        super(HiddenSlideForm, self).__init__(*args, **kwargs)
        for name, field in self.fields.iteritems():
            field.widget = field.hidden_widget()
            field.required = False

and then I have another class:

class DeckForm(ModelForm):     

    def __init__(self, *args, **kwargs):
        # do some stuff here
        return super(DeckForm, self).__init__(*args, **kwargs)

    class Meta:
        model = Deck
        # other stuff here  

which I also sub-class:

class HiddenDeckForm(DeckForm):

    def __init__(self, *args, **kwargs):
        super(HiddenDeckForm, self).__init__(*args, **kwargs)
        for name, field in self.fields.iteritems():
            field.widget = field.hidden_widget()
            field.required = False

Note that the subclasses have the exact same code other than class names and do the exact same thing. I have been trying to figure what the best way to genericize this so I can keep it DRY and easily use it for other classes, and have considered decorators and/or multiple inheritance–both of which are new concepts for me–but I keep getting mixed up.

Help is appreciated!

(As a side note, feel free to point out any problems you see in my django code 🙂 )

Answer 1

One option is to use a Mixin class; example:

First, the common behavior goes in the mixin:

class SomeMixin(object):
    def __init__(self, *args, **kwargs):
        super(SomeMixin, self).__init__(*args, **kwargs)
        for name, field in self.fields.iteritems():
            field.widget = field.hidden_widget()
            field.required = False

To the extent that you are in reasonable control of all of the classes in the inheritance graph, and so long as you call super in every method that needs to be overridden, then it doesn’t matter too much what the derived classes look like.

However, you run into a problem when one of the superclasses does not itself call super at the correct time. It’s very important that the overridden method, in that case, must be called last, since once it’s called, no more calls will be made.

The simplest solution is to make sure that each class actually derives from the offending superclass, but in some cases, that’s just not possible; deriving a new class creates a new object that you don’t actually want to exist! Another reason might be because the logical base class is too far up the inheritance tree to work out. \

In that case, you need to pay particular attention to the order in which base classes are listed. Python will consider the left-most superclass first, unless a more derived class is present in the inheritance diagram. This is an involved topic, and to understand what python is really up to, you should read about the C3 MRO algorithm present in python 2.3 and later.

Base classes as before, but since all of the common code comes from the mixin, the derived classes become trivial

class HiddenSlideForm(SomeMixin, SlideForm):
    pass

class HiddenDeckForm(SomeMixin, DeckForm):
    pass

Note that the mixin class appears first, since we can’t control what the *Form classes do in their init methods.

If the __init__ methods of either are non-trivial, you still get a win.

class HiddenSlideForm(SomeMixin, SlideForm):
    def __init__(self, *args, **kwargs):
        super(HiddenSlideForm, self).__init__(*args, **kwargs)
        do_something_special()

---

Make sure that object is in the inheritance diagram, somewhere. Strange things can happen otherwise.