Neil Toronto wrote:
Because the runtime enforces isinstance(D_instance, D), everything else can be handled with D_instance.method(...) or self.method() or super.method().
But super() is not a general replacement for explicit inherited method calls. It's only appropriate in special, quite restricted circumstances.
Exactly. There are two common method-calling cases, and an uncommon one. In order of expected number of occurrences, with #3 being quite low: 1. self.method(...) 2. super.method(...) 3. DistantParent.method(self, ...) (either to get out of the MRO or because you're feeling evil - two use cases for it) If self were only implicitly available, #3 would need a new spelling, as you say. That's not hard to do, and I've already suggested as_parent(DistantParent, self).method(...) as an alternate spelling for the uncommon cases. That's not to say I'm advocating such a thing for Python 3.0 - just showing that it's possible to cover the current known use cases. Actually, I suspect there aren't any more use cases, as all correct ways of calling the method (those that don't raise an exception) are covered, and implicit self would still be as accessible from anywhere as explicit self is. Would saving six keystrokes per method, reducing noise in every method header, and removing the need for a habit (always including self in the parameter list) be enough to justify a change? I'm going to guess either "no" or "not right now". If I were doing it from scratch, I'd make self and super into keywords, and change method binding to return a function with them included in the locals somehow. Neil