Already in the first 5 minutes we have a glaring error. Multiple inheritance in python _never_ works, because there's no such thing as "classes without overlapping methods", because __init__ always overlaps, which means it's impossible to call __init__ correctly, which means it's flatly impossible to use multiple inheritance correctly in python. The author of super considered harmful understood this. You don't. Drop the smug and try to learn something.

Second glaring error, C3 linearization is not a "best and optimum solution to this problem", because it's not a solution to this problem in any sense. Turning multiple inheritance into single inheritance means there's no multiple inheritance at all, so you didn't solve the problem, so the thing doesn't. fricking. work. Funnily enough, multiple inheritance in C++ works just fine. You can use it. It works. You don't have to make all the classes aware of one another and demolish encapsulation to make it work. The author of super considered harmful understood this. You don't. Drop the smug and try to learn something.

More glaring errors I didn't bother to mention, but Pizza inheriting from DoughFactory? Come on.

No, it's not awesome that you can change the parent from the child, actually. It's insane, brittle, and impossible to use correctly. "is this fragile? no, it's deterministic" so is everything in programming. It's _extremely_ brittle. That's all the incompetence I can stomach, I'm afraid.

1. The same, just inject previously into the class you need. No, the entire app does not become 1 class. 2. Not sure what you mean by 'track down'? Don't overcomplicate things, ptyhon design is different. Don't bring here fancy terms like 'method signatures', they don't make sense in this context. 3. Change your code. 4. Good point. The method resolution order will resolve to the first one encountered if you use super with no arguments. Super can be used with arguments that direct its resolution. So, without arguments, it resolves with the c3 algorithm. With arguments you can call 1 or both in the order you need ( In that specific case you do introduce a little redundancy, but you have no choice). 5. Again, python is more abstract. An interface is just a contract or a declaration of behavior. You could just class Interface: def act(self): pass class Imp(Interface): pass You could use the ABC (Abstract Base Class) module to decorate and express and force the interpreter to put some restrictions, like, not implementing Interface.act method. Don't let them confuse you with fancy words 'implements' 'extends' and 'injection', behind the scenes there are just objects and pointers. In Python, I don't care if put my dependency inside the parenthesis of a class declaration if I'm given the dependency at the instance creation level or if I fucking give a framework a yaml file that declares my dependencies and makes the symbols available at the necessary scope. It's a matter of understanding the best approach for you. Again, in this case, is trivial, discussing the 'is-a' or 'has-a' thing is a waste of time and is inherited by old paradigms. The difference is just this: class Dependant(Dependency): # what you call 'is-a' pass or class Dependant: # what you call 'has-a' def __init__(self, dependency): self.dependency = dependency or, if you want a framework: dependencies.yaml Dependant Dependency -- Then in your code: Dependant().dependency.method_on_dependency() Do you see how dumb it is to waste time discussing this? It's nice as a learning exercise but at the end of the day, why the hell i would go and create a file and install a framework if I can just write class A(B): pass? What is the advantage of expressing this particular case in a file instead of in the code file itself? If you find dependencies later, just go and add a new dependency to your class Instantiation (Yes, classes in Python are first-class citizens). You are too biased. If your dependency is against an interface, and you know it, then add the interface. If you don't know it, it is not a problem with the language. That's it. When you call the method it will just do nothing, or again, you can decorate to enforce classic oo behavior like raising a NotImplemented error and stuff like that, or even raise a not implemented error. Python is very abstract and that is why it gives you so much flexibility. These ideas become clear to you when you become older. You need to work in too many different areas and technologies to understand all is reduced to a matter of convenience and automation. Some principles should guide you, but these are not dependent on the technologies. Behind the scenes, all is reduced to objects and pointers. How do you think a class Inheritance is resolved inside the compiler? So, for example, they say "Favor composition over inheritance". Ok. That may be good for Java | C# | C++ but, what if I have a language that has a method resolution and leaves me to declare my dependencies at class Instantiation level, I mean here: class A(B, C). Then what is the difference between receiving the dependency from a config file, or 'injected' at the instance instantiation level? I can test and refactor at any time. Convenience, Man. Hope you undersand.

Corey Schafer is also great.