"inherited" keyword in Python?
Paul Foley
see at below
Tue Dec 5 20:30:35 EST 2000
On Tue, 5 Dec 2000 22:11:08 +0100, Alex Martelli wrote:
> To clarify: Python's rule (as applied by, e.g., getattr) is anything
> but broken, but it doesn't easily let you return (for a given class X
Python's rule works for Python, sure -- but Python doesn't provide any
way to call a superclass method without knowing exactly what you want
to call (else all this would be unnecessary!)
> that inherits from A, B, C, ...) a single class Z that will ensure that
> getattr(Z,whatever) is the same as getattr(X,whatever) for any
> whatever that is not a key in X.__dict__.
I'm not sure that's all that's needed, though.
>> that won't work. I thought super() was just supposed to call the
>> appropriate same-named method of a parent class. Anything else can be
>> done through the usual self.whatever, surely?
> Not really. To translate literally a Java class which has methods X
> (which calls the base's Y) and Y (which calls the base's X method),
> I'd need a Python's super() to be like Java's super (returning a class
I've never bothered with Java. How can you write a method X which
calls the base's Y without explicitly calling the base's Y? And if
you have to do it explicitly, that'll work in Python, too.
> object reference) and not like what I name 'supercall'. self.X and
> self.Y just won't do for this.
It seems to me, what you said above about Java notwithstanding, that
the only time it's OK to call X where X is a method in a base class,
and where self.__class__ also has a method named X (so that self.X()
will do the wrong thing), is from inside self.X.
>> > But, how often is it going to be satisfactory to call 'just
>> > the one' (of several) inherited-method of a certain name, in
>> > a multiple-inheritance context? Just as often we may want
>>
>> It isn't (at least, not to me), which is why I avoided doing it that
> But you did do that -- you call just one of the several 'inherited'
> implementations of the method, in the code below.
Any one call to super() only calls one method, naturally. But if
everyone calls super() _all_ the methods eventually get called. Under
"Python rules", only the methods in D, B and A can ever run -- the one
in C never does, unless called explicitly with C.foo(self) from D; and
in that case, it's called out of order -- you either get D, B, A, C or
D, C, B, A, or, more likely D, B, A, C, A or D, C, A, B, A, with A.foo
getting called twice, since both B and C inherit A. This sucks. I
get D, B, C, A, which is the right order (B.foo and C.foo are both
called before their common superclass's A.foo, B.foo is called before
C.foo since B is to the left of C in D.__bases__) and A.foo is only
called once.
>> way. Having figured out how to get the frame info, here's an
>> implementation. No need to pass in the object and method name:
> I'd still want to pass them, at least optionally, to handle the
> above case where I want to call a _different_ inherited method.
I'm working on the assumption that if you want to do that, you're
doing something wrong.
>> If you just call super(__thisclass) with no args other than the class,
>> it passes on the args the calling method got; or you can specify other
>> args explicitly [yes, I know this prevents you calling with no args if
>> super's caller has args]
> As, once again, convenience gets in the way of simplicity and
Maybe. This is an attempt to copy the CALL-NEXT-METHOD functionality
of CLOS; in CLOS, all the methods will have similar argument lists,
because they're all part of one generic function, not independent
members of various classes. Just chop out the 5 lines in the middle
that copy the caller's arglist if you think it's better not to do
this.
> generality. Oh well:-). "Tantum convenientia potuit suadere
> malorum", as Lucretius might write if he lived today!-)
[Am I supposed to be one of them? And shouldn't "malorum" be dative?]
--
Cogito ergo I'm right and you're wrong. -- Blair Houghton
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
More information about the Python-list
mailing list