(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. Neil