[MAL, on basemethods]
> ...
> In other words: you let Python continue the search for the method
> as if it hadn't found the occurrance calling the bsaemethod()
> API. Hmm, still not clear enough... better let Tim jump in here
> (we've had a discussion about basemethod() some months or years
> ago). Tim ?
Sorry, I'm not sure what either of you is talking about. In
class A(B, C):
def foo(self):
super.foo()
Guido said that super would start searching at B, but I don't know what your
"continue the search for the method as if it hadn't found the occurrance
calling the bsaemethod() API" means: defining what a thing does in terms of
an unspecified API it doesn't use is a pretty sure recipe for compounded
confusion <wink>.
Given that we're using Python's search rules, the ambiguous point remaining
is whether:
super.f()
textually contained in a method of class K begins searching with:
1) K.__bases__
or with:
2) self.__class__.__bases__
Java uses #1, and Guido's "the search starts with B" implies that he would
too. But it's unclear whether he meant that. Given also
class D(A):
def foo(self):
super.foo()
D().foo()
both views agree that D.foo() is invoked first, and that D.foo() invokes
A.foo() next. But under #1 A.foo() invokes C.foo() or D.foo() next, while
under #2 A.foo() invokes A.foo() again. Multiple inheritance is a red
herring here -- take C out of A's bases, and the same ambiguity needs to be
resolved.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4