[Python-ideas] Explicit self argument, implicit super argument
Jim Jewett
jimjjewett at gmail.com
Tue Nov 20 16:15:56 CET 2007
On 11/20/07, ntoronto at cs.byu.edu <ntoronto at 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
More information about the Python-ideas
mailing list