super - is (should) it (be) a reserved word?

Alex Martelli aleaxit at yahoo.com
Mon Oct 9 04:39:04 EDT 2000


"Michal Wallace" <sabren at manifestation.com> wrote in message
news:mailman.971064623.25775.python-list at python.org...
> On Mon, 9 Oct 2000, Greg Ewing wrote:
>
> > Alex Martelli wrote:
> > >
> > > self.__class__.__bases__[0] satisfies this request, I think.
> >
> > Not when there is more than one level of inheritance
> > involved. The class you want to find the base class
> > of isn't the class of self, it's the class where the
> > currently executing method was defined, and there's
> > currently nothing in Python that keeps track of that.
>
> Why do you need that? Calling a method of a class
> climbs the hierarchy for you, all the way up to where
> the method was first defined or last overridden.

The purpose of the request for "super" is, presumably, to
help those typical overrides that may also need to call
the method version they are overriding as a part of their
operation.  Assuming single inheritance (maybe because of
a Smalltalk background by the requester[s]), it is then
considered handier to call super.method(foo) than to have
to know the name of the class whose method is being
overridden in order to call Baseclass.method(self,foo).

If "super" needs to indicate a different class each time
it's named, depending on the method in which it is named,
then the problem looks difficult indeed.  Is this the
exact Smalltalk semantic?  I was not aware of that -- I
thought that "super", like in Java, would rather indicate
the immediate superclass.  If there's such a subtle and
treacherous semantic nuance between 'super' in Smalltalk
and in Java, then this may be a reason to avoid mimicking
it in Python -- can't make both camps happy, after all.

As for "the class that defined the method (which may be a
base class of the class of which im_self is an instance)",
this is exactly the definition (3.2 in the Reference
Manual) of the im_class of the method object.  Therefore,
within method foo, foo.im_class.__bases__[0] should be
able to play the same role as I envisaged, above, for
self.__class__.__bases__[0].

It should still be possible to write a super() function
that will return such a class -- by finding out what
method it's been called from, raising an exception if
not called from a method, etc.  And a mixin approach,
such as I suggested, might still artificially synthesize
(and presumably cache) an object of that class to be
returned - if, that is, super() can be written.

Trying to put this in practice, the first difficulty
is that one can easily get to the code-object (via the
traceback and frame objects), but not from that back
to the method-object (and thus via im_class to the
class whose 'super' is actually of interest).  Am I
having a spot of localized blindness, or is it in fact
a problem...?


Alex






More information about the Python-list mailing list