[Python-3000] [Fwd: features i'd like [Python 3000] ... #3: fix super()]
thomas at python.org
Wed Dec 6 22:59:55 CET 2006
On 12/6/06, Jan Grant <jan.grant at bristol.ac.uk> wrote:
> On Mon, 4 Dec 2006, Ben Wing wrote:
> > as a result, i imagine there's a strong urge to just hardcode the name
> > of the parent
> > -- super.meth(args) calls the superclass method `meth'
> Python supports multiple inheritance, unlike Java; the design mantra is
> "explicit is better than implicit" and "ambiguity should be an error".
> Two! The two design mantras are...
You forget that that's actually what super() is for. It does the right thing
in the case of MI (and every other case, in fact :-)
> -- as an alternative or in addition, super(args) would work like
> > super.meth(args) if we're currently inside of `meth' in a subclass. i
> > suspect that 90% of the time or more, `super' is used to chain to the
> > superclass version of an overridden method, and this optimizes for the
> > common case.
> Commonly you know what the method is called at the point where you're
> typing "super" :-)
The point is not that it's difficult to come up with the arguments to
super(ThisClass, self).methodname(args), but that it's tedious and sometimes
unobvious and error-prone. super should definately be enhanced so
'super(args)' and 'super.meth' 'do the right thing' too, but as Nick said,
it's not that easy :) It would help if someone started on an implementation
though. (It's on my TODO list, but that list is rather swamped with "new
(For an example of 'tricky things', when you do:
def meth(self, x, y):
return super(x) + y
moremeth = meth
-- should X().moremeth(1, 2) call Y.meth() or Y.moremeth()? It could
probably be implemented either way, with enough magic in the runtime.)
Thomas Wouters <thomas at python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000