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

John J. Lee phrxy at csv.warwick.ac.uk
Mon Oct 9 14:10:49 EDT 2000


On Mon, 9 Oct 2000, Alex Martelli wrote:

> "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).

Yes, because if the class from which you inherit changes later, you
probably don't have to change your method calls in the subclass (according
to, dare I say it, the perltoot manpage by Tom Christiansen).

> 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.

You may well not consider this an argument in favour of the Smalltalk
approach, but Perl seems to do it the same way:

#!/usr/bin/perl -w

package Foo;

sub new {
	my $self = {};
	$self->{foo} = 'foo';
	bless($self);
	return($self);
}

sub foo {
	my $self = shift;
	print "in Foo::foo\n";
	return $self->{foo};
}

package Bar;
@ISA = qw(Foo);

sub new {
	my $self = {};
	$self->{foo} = 'bar';
	bless($self);
	return($self);
}

sub foo {
	my $self = shift;
	print "in Bar::foo\n";
	return $self->SUPER::foo();
}

package Baz;
@ISA = qw(Bar);

sub new {
	my $self = {};
	$self->{foo} = 'baz';
	bless($self);
	return($self);
}

print "Foo object:\n";
$object = new Foo;
print $object->foo()."\n\n";


which prints:

Foo object:
in Foo::foo
foo

Bar object:
in Bar::foo
in Foo::foo
bar

Baz object:
in Bar::foo
in Foo::foo
baz


rather than:

[blah blah...]
Baz object:
in Bar::foo
in Bar::foo
in Bar::foo
[and then presumably going into an 'infinite' loop]

I'm new to object oriented things, so I may be confused about this.

> 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].

Sounds like that's the right thing.

> 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.

A what approach?

> 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...?
[...]

No idea!


John




More information about the Python-list mailing list