This thread is a little head-spinning. OP and replies are almost as difficult to understand as the official documentation of super() :D I'm not going to pile on, but I will provide an example I recently worked on that illustrated to me both the difficulties and possibilities of the current system. I'm just going to present the problem, not my solution (sorry). I hate the often over-simplified examples that are included in these sort of discussions, but a lot of us would probably be fired if we ever posted real world examples here, so... Let's say we have one of your class-ical ( :D ) geometrical shapes hierarchy, including an abstract Shape class. ``` class Shape(abc.ABC): @abc.abstractmethod def area(self): """""" class Circle(Shape): def __init__(self, r): self.r = r def area(self): return 3.14159*self.r**2 class Conic(Circle): def __init__(self, r, k): super().__init__(r) self.k = k def area(self): """ Imagine it's a formula """ ``` This is pretty close to my real life example. Now, in my real life example, what I have a need, or perhaps I should say a strong desire for, is the ability to assign callback or property to these parameters r or k, or whatever else. I could re-write these classes so that all parameters are explicitly callbacks, but then consumers of this library would need to adjust their use accordingly. I could re-implement the __init__ functions, use hidden private variables, and add properties to achieve the same effect. I could even write decorators to reduce the amount of copy-pasta needed to make it all work. But this would, in my situation, likely discourage other potential collaborators from making contributions to the code. In my mind, the best way to make the code work, and promote use and contribution to it, is to make it so that users can pass in callables instead of fixed values to __init__, and the machinery that returns an object will create properties to represent that value if it is a callable, otherwise attributes as shown above. I will not detail my solution here, but if you know how properties work, then you know that this solution requires classes to be generated on the fly. This problem was a tough nut to crack, and I'm only 95% happy with my solution. It eventually consisted of custom metaclasses and a __new__ each for both the metaclasses and the "real" classes. Don't forget, the base class is an abstract base class, which has its own metaclass. I did eventually get it to work with an acceptable amount of hoops to jumps through for potential collaborators, and none for potential users. But it was not made any easier by the current implementation of super(), and definitely not by the lack of detailed documentation on what exactly super() does. "Returns a proxy..." - but what is a proxy? If you ever really need to know, you might be in for a long night.