sue server ('sue'bob salarysue salary ( watch what happensthoughwhen an employee is member of both categories because the constructors in the tree have differing argument listswe're in troubleclass twojobs(chef server )pass tom twojobs('tom'typeerror__init__(takes positional arguments but were given the problem here is that the super call in chef no longer invokes its employee superclassbut instead invokes its sibling class and follower on the mroserver since this sibling has differing argument list than the true superclass--expecting just self and name--the code breaks this is inherent in super usebecause the mro can differ per treeit might call different versions of method in different trees--even some you may not be able to anticipate when coding class by itselftwojobs __mro__ (chef __mro__ (by contrastthe direct by-name call scheme still works when the classes are mixedthough the results are bit dubious--the combined category gets the pay of the leftmost superclassclass twojobs(chef server )pass tom twojobs('tom'tom salary reallywe probably want to route the call to the top-level class in this event with new salary-- model that is possible with direct calls but not with super alone moreovercalling employee directly in this one class means our code uses two dispatch techniques when just one--direct calls--would sufficeclass twojobs(chef server )def __init__(selfname)employee __init__(selfname tom twojobs('tom'tom salary class twojobs(chef server )def __init__(selfname)super(__init__(name tom twojobs('tom'typeerror__init__(takes positional arguments but were given the super built-in functionfor better or worse