Interesting. I don't really mess with the class hierarchy all that
often, but if I did, I'd consider using the current facilities for
supporting the above construct, rather than proposing an extension
;-). Specifically, the above could be written:
> class a:
> def m(self): ...
> class b(a):
> def m(self): ... b.__bases__[0].m() ... # Calls a.m()
> class c(b):
> def m(self): ... c.__bases__[0].m() ... # Calls b.m()
and if you use the above standard construct, the answer to your second
question:
> How it would work with multiple inheritance: I don't know.
also falls out. (The other way to look at it is that your "parent"
extension would really have to be a tuple or array... which is really
what "__bases__" already is ;-) )
For those that that want to take it "a step further," I'd warn that the
following will NOT work:
> class a:
> def m(self): ...
> class b(a):
> def m(self): ... self.__class__.__bases__[0].m() ... # WON'T always Call a.m()
> class c(b):
> def m(self): ... self.__class__.__bases__[0].m() ... # WON'T always Call b.m()
I leave it to the reader to identify the problem :-). Hint: Construct
a "c", and call "c.m()" and watch the infinite loop (till the stack
blows).
Jim
Jim Roskind
voice: 408.982.4469
fax: 408.986.1889
jar@infoseek.com