On 19 Nov 2007, at 20:42, Neil Toronto wrote:
[...]
Now, correct me if I'm wrong, but it seems there are only two use cases for DistantParentOfD.method(D_instance, ...):
1. The Good Case: you know the "next-method" as determined by the MRO isn't the right one to call. Multiple inheritance can twist you into this sort of behavior, though if it does, your design likely needs reconsideration.
2. The Evil Case: you know the override method as defined by D isn't the one you want for your extra-special D instance. This should be possible but never encouraged.
Because the runtime enforces isinstance(D_instance, D), everything else can be handled with D_instance.method(...) or self.method() or super.method(). We know that #1 and #2 above are the uncommon cases, which is why the new "super", which covers the common ones, doesn't cover those.
Is it right to say that the explicit "self" parameter only exists to enable those two uncommon cases?
Self being explicit makes it less selfish :) To illustrate, I like that you can do: class Foo(str): def mybar(self): class Bar(str): def madeby(me): return "I am %s and I was made by %s" % (me, self) return Bar
foo=Foo("foo") bar=foo.mybar() Bar=foo.mybar() bar=Bar("bar") print bar.madeby() I am bar and I was made by foo
This depends on 'self' being explicit and is not related to super. I didn't know about implicit super, it's probably great but my initial reaction is that I don't like it :( Why not: class Foo: @with_super def bar(super, self, x, y): super.bar(x, y) ... -- Arnaud