On 11/20/07, ntoronto@cs.byu.edu <ntoronto@cs.byu.edu> wrote:
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.
I would say it it almost always appropriate. The times it fails are when (1) You want to change the name of the method. Fair enough -- but you can usually forward to self.othername (2) You want to change the arguments of the method. Changing the signature is generally a bad idea, though it is tolerable for constructors. (3) You're explicitly managing the order of super-calls (==> fragile, and the inheritance is already a problem) (4) Backwards compatibility with some other class that uses explicit class names instead of super. Number 4 is pretty common still, but it is just a backwards compatibility hack that makes code more fragile.
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.
Agreed. The fact that method parameter lists look different at the definition and call sites is an annoying wart, but ... too late to change. -jJ