Search code examples
pythoninheritancemixins

Motivation for the convention of appending "Mixin" to non-instantiated python classes that I want to define shared methods in?

Background:

The answers to this post helped me understand the design pattern and why it's useful. However, I can't find anything on docs.python.org on the term "mixin" or how the notion of 'non-instantiated multiple-inheritance' is formalized.

Questions:

  1. Where does the term "mixin" come from and how does python know a class is a mixin if the "*Mixin" pattern is not reserved?
  2. Is there any motivation (besides convention) to append "Mixin" to classes that I want to use for shared methods that don't get inherited from a parent class?
Solution
    1. Where does the term "mixin" come from and how does python know a class is a mixin if the "*Mixin" pattern is not reserved?

    The term is used in OOP, but I believe it just surfaced naturally, as it the counterpart of what a "real world" "thing to be mixed in the final result" would do; it means literally something that is mixed-in your final result, and changes its behavior.

    As for Python recognizing it: it does not. Python only knows about classes, and you can name your composible superclasses as you want. There is no need to add a "Mixin" suffix to their name - it is not even a strong convention at all: if it does not make sense in your project so that it is easier to understand, feel free to name your classes as you want.

    A much stronger convention the language does not care about either (except in some few "soft" places) is that "_" should be use to denote private methods or attributes in Python code. Besides that, the only names that Python care about are special names that are prefixed and post-fixed with two underlines - "__"

    1. Is there any motivation (besides convention) to append "Mixin" to classes that I want to use for shared methods that don't get inherited from a parent class?

    As stated above, no. Just name them as you want.