Guido van Rossum wrote:

The reason for explicit self in method definition signatures is semantic consistency. If you write

class C: def foo(self, x, y): ...

This really *is* the same as writing

class C: pass

def foo(self, x, y): ... C.foo = foo

And of course it works the other way as well: you really *can* invoke foo with an explicit argument for self as follows:

class D(C): ...

C.foo(D(), 1, 2)

IOW it's not an implementation hack -- it is a semantic device.

Ah, thanks, that helps. (I'll be able to sleep tonight. :D) This semantic device, of course, would really suck if applied to "super": d = D() C.foo(d, super(C, d), 1, 2) # strange and hideous which is a great reason that the new "super" is implicit. (Before I continue, please understand that I'm not arguing for a language change. Responses to my last two ideas have shown me that I need to thoroughly understand why things are as they are right now while considering a change, and long before advocating one. It also goes over better with the language designers.) 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? Of course, if self were implicit, there would still need to be a way to spell DistantParentOfD.method(D_instance, ...). Being the uncommon case, maybe it shouldn't have a nice spelling: as_parent(C, D_instance).method(...) Trying-to-understandingly-yours, Neil

Arnaud Delobelle wrote:

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() # typo Bar=foo.mybar() bar=Bar("bar") print bar.madeby() I am bar and I was made by foo

Ah, I see. If self were passed implicitly, you would need to make a Bar.__init__ that received and stored the outer self. I think I'd call this a third uncommon case. Outside functional idioms, common is usually flat.

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

Probably because it's way too common to require a decorator for it. Users would have to make "always use @with_super" into a coding habit. (Sort of like "self" actually.) It'd also be yet another thing to keep in mind while reading code: did this method use @with_super or not? Neil

Luke Stebbing wrote:

On 11/19/07, Arnaud Delobelle wrote:

...

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

How about:

class Foo(str): def mybar(): outer = self class Bar(str): def madeby(): return "I am %s and I was made by %s" % (self, outer) return Bar

Good point. I actually like this better, since it forces the outer scope self to have a different name, removing a source of confusion. Back down to two uncommon use cases so far, then. Neil

Neil Toronto wrote:

Because the runtime enforces isinstance(D_instance, D), everything else can be handled with D_instance.method(...) or self.method() or super.method().

But super() is not a general replacement for explicit inherited method calls. It's only appropriate in special, quite restricted circumstances. -- Greg

On 11/20/07, ntoronto@cs.byu.edu wrote:

...

Neil Toronto wrote:

...

Because the runtime enforces isinstance(D_instance, D), everything else can be handled with D_instance.method(...) or self.method() or super.method().

...

But super() is not a general replacement for explicit inherited method calls. It's only appropriate in special, quite restricted circumstances.

I would say it it almost always appropriate. The times it fails are when (1) You want to change the name of the method. Fair enough -- but you can usually forward to self.othername (2) You want to change the arguments of the method. Changing the signature is generally a bad idea, though it is tolerable for constructors. (3) You're explicitly managing the order of super-calls (==> fragile, and the inheritance is already a problem) (4) Backwards compatibility with some other class that uses explicit class names instead of super. Number 4 is pretty common still, but it is just a backwards compatibility hack that makes code more fragile.

Would saving six keystrokes per method, reducing noise in every method header, and removing the need for a habit (always including self in the parameter list) be enough to justify a change? I'm going to guess either "no" or "not right now". If I were doing it from scratch, I'd make self and super into keywords, and change method binding to return a function with them included in the locals somehow.

Agreed. The fact that method parameter lists look different at the definition and call sites is an annoying wart, but ... too late to change. -jJ

ntoronto@cs.byu.edu wrote:

There are two common method-calling cases, and an uncommon one. In order of expected number of occurrences, with #3 being quite low:

1. self.method(...)

2. super.method(...)

3. DistantParent.method(self, ...)

You're still missing an important case. I would rank them as 1. self.method(...) 2. DirectParent.method(self, ...) 3. super.method(...) 4. DistantParent.method(self, ...) Anything that made number 2 difficult would be unacceptable. -- Greg

On 11/19/07, Greg Ewing wrote:

Neil Toronto wrote:

...

class A(object): def method(self, x, y): self.x = x super.method(y)

Is that really how it's going to be? What if self isn't called 'self'?

I would rather see

super.method(self, y)

PEP 3135 specifies that the first argument of the method is used, regardless of name: http://www.python.org/dev/peps/pep-3135/#specification Luke