It seems that the frustration with super revolves around how Python currently conflates (as well as many users) two very different types of inheritance, both "is-a" and "has-a" (or compositional) inheritance. Unfortunately, Python assists this confusion because the language doesn't provide a distinct enough way to differentiate between them. For the former (i.e. is-a inheritance), users should not have to explicitly make a call to the super class (via super() or otherwise)--this should be automatic for every method held in common so as to guarantee the invariants of the simpler class. For this type of inheritance it makes more sense to be explicit about *bypassing* a call to the parent class--IF necessary (perhaps to take advantage of an optimization available only in the subclass)--rather than explicit about *making* one. This would remove many of the bugs, misuses, and frustrations with super(). No more ambiguity and confusion because the language now guarantees certain behavior. Super() would then be limited to cooperative mixin classes; for all others, explicit naming of the class would be required. But perhaps that there is some language abstraction that has yet to be fully invented that would tie it all together nicely. By the way, regarding your trait implementation, it may be worthwhile revisiting the discussion surrounding the Prothon language discussed a few years ago on comp.lang.python which got rid of classes and metaclasses and replaced them with prototypes. Regards, zipher