atom feed17 messages in org.python.python-ideas[Python-ideas] Explicit self argument...
FromSent OnAttachments
Neil TorontoNov 19, 2007 11:00 am 
Guido van RossumNov 19, 2007 11:11 am 
Luke StebbingNov 19, 2007 12:20 pm 
Neil TorontoNov 19, 2007 12:42 pm 
Arnaud DelobelleNov 19, 2007 1:54 pm 
Neil TorontoNov 19, 2007 2:03 pm 
Greg EwingNov 19, 2007 4:33 pm 
Greg EwingNov 19, 2007 5:23 pm 
Luke StebbingNov 19, 2007 5:27 pm 
Luke StebbingNov 19, 2007 5:50 pm 
Neil TorontoNov 19, 2007 6:37 pm 
Arnaud DelobelleNov 19, 2007 11:05 pm 
ntoronto at cs.byu.eduNov 20, 2007 12:50 am 
Jim JewettNov 20, 2007 7:15 am 
Greg EwingNov 20, 2007 3:48 pm 
Greg EwingNov 20, 2007 4:43 pm 
Ali Gholami RudiNov 20, 2007 8:54 pm 
Subject:[Python-ideas] Explicit self argument, implicit super argument
From:Guido van Rossum (
Date:Nov 19, 2007 11:11:21 am

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): ... = 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): ..., 1, 2)

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


On Nov 19, 2007 11:00 AM, Neil Toronto <ntoronto at> wrote:

(Disclaimer: I have no issue with "self." and "super." attribute access, which is what most people think of when they think "implicit self".)

While showing a coworker a bytecode hack I made this weekend - it allows insertion of arbitrary function parameters into an already-existing function - he asked for a use case. I gave him this:

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

where 'method' is replaced by this method wrapper via metaclass or decorator:

def method_wrapper(self, *args, **kwargs): return hacked_method(self, super(cls, self), *args, **kwargs)

These hackish details aren't important, the resulting "A.method" is.

It occurred to me that explicit self and implicit super is semantically inconsistent. Here's Python 3000's version of the above (please compare):

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

Why have a magic "super" local but not a magic "self" local? From a *general usage* standpoint, the only reason I can think of (which is not necessarily the only one, which is why I'm asking) is that a person might want to change the name of "self", like so:

class AddLike(object): # ... def __add__(a, b): # return something def __radd__(b, a): # return something

But reverse binary special methods are the only case where it's not extremely bad form. Okay, two reasons for explicit self: backward compatibility, but 2to3 would make it a non-issue.

From an *implementation standpoint*, making self implicit - a cell variable like super, for example - would wreak havoc with the current bound/unbound method distinction, but I'm not so sure that's a bad thing.