method more to the pointby making mix-ins more self-containeddirect calls minimize component coupling that always skews program complexity higher-- fundamental software principle that seems neglected by super' variable and context-specific dispatch model customizationsame-argument constraints as final noteyou should also consider the consequences of using super when method arguments differ per class--because class coder can' be sure which version of method super might invoke (indeedthis may vary per tree!)every version of the method must generally accept the same arguments listor choose its inputs with analysis of generic argument lists--either of which imposes additional requirements on your code in realistic programsthis constraint may in fact be true showstopper for many potential super applicationsprecluding its use entirely to illustrate why this can matterrecall the pizza shop employee classes we wrote in as coded thereboth subclasses use direct by-name calls to invoke the superclass constructorfilling in an expected salary argument automatically--the logic being that the subclass implies the pay gradeclass employeedef __init__(selfnamesalary)self name name self salary salary class chef (employee)def __init__(selfname)employee __init__(selfname common superclass differing arguments dispatch by direct call class server (employee)def __init__(selfname)employee __init__(selfname bob chef ('bob'sue server ('sue'bob salarysue salary ( this worksbut since this is single-inheritance treewe might be tempted to deploy super here to route the constructor calls generically doing so works for either subclass in isolationsince its mro includes just itself and its actual superclassclass chef (employee)def __init__(selfname)super(__init__(name class server (employee)def __init__(selfname)super(__init__(name advanced class topics dispatch by super(