Why do you need explicitly have the "self" argument in a Python method?

Question

When defining a method on a class in Python, it looks something like this:

class MyClass(object):
    def __init__(self, x, y):
        self.x = x
        self.y = y

But in some other languages, such as C#, you have a reference to the object that the method is bound to with the "this" keyword without declaring it as an argument in the method prototype.

Was this an intentional language design decision in Python or are there some implementation details that require the passing of "self" as an argument?

Solution 1

I like to quote Peters' Zen of Python. "Explicit is better than implicit."

In Java and C++, 'this.' can be deduced, except when you have variable names that make it impossible to deduce. So you sometimes need it and sometimes don't.

Python elects to make things like this explicit rather than based on a rule.

Additionally, since nothing is implied or assumed, parts of the implementation are exposed. self.__class__, self.__dict__ and other "internal" structures are available in an obvious way.

Solution 2

It's to minimize the difference between methods and functions. It allows you to easily generate methods in metaclasses, or add methods at runtime to pre-existing classes.

e.g.

>>> class C:
...     def foo(self):
...         print("Hi!")
...
>>>
>>> def bar(self):
...     print("Bork bork bork!")
...
>>>
>>> c = C()
>>> C.bar = bar
>>> c.bar()
Bork bork bork!
>>> c.foo()
Hi!
>>>

It also (as far as I know) makes the implementation of the python runtime easier.

Solution 3

I suggest that one should read Guido van Rossum's blog on this topic - Why explicit self has to stay.

When a method definition is decorated, we don't know whether to automatically give it a 'self' parameter or not: the decorator could turn the function into a static method (which has no 'self'), or a class method (which has a funny kind of self that refers to a class instead of an instance), or it could do something completely different (it's trivial to write a decorator that implements '@classmethod' or '@staticmethod' in pure Python). There's no way without knowing what the decorator does whether to endow the method being defined with an implicit 'self' argument or not.

I reject hacks like special-casing '@classmethod' and '@staticmethod'.

Solution 4

Python doesn't force you on using "self". You can give it whatever name you want. You just have to remember that the first argument in a method definition header is a reference to the object.

Solution 5

Also allows you to do this: (in short, invoking Outer(3).create_inner_class(4)().weird_sum_with_closure_scope(5) will return 12, but will do so in the craziest of ways.

class Outer(object):
    def __init__(self, outer_num):
        self.outer_num = outer_num

    def create_inner_class(outer_self, inner_arg):
        class Inner(object):
            inner_arg = inner_arg
            def weird_sum_with_closure_scope(inner_self, num)
                return num + outer_self.outer_num + inner_arg
        return Inner

Of course, this is harder to imagine in languages like Java and C#. By making the self reference explicit, you're free to refer to any object by that self reference. Also, such a way of playing with classes at runtime is harder to do in the more static languages - not that's it's necessarily good or bad. It's just that the explicit self allows all this craziness to exist.

Moreover, imagine this: We'd like to customize the behavior of methods (for profiling, or some crazy black magic). This can lead us to think: what if we had a class Method whose behavior we could override or control?

Well here it is:

from functools import partial

class MagicMethod(object):
    """Does black magic when called"""
    def __get__(self, obj, obj_type):
        # This binds the <other> class instance to the <innocent_self> parameter
        # of the method MagicMethod.invoke
        return partial(self.invoke, obj)


    def invoke(magic_self, innocent_self, *args, **kwargs):
        # do black magic here
        ...
        print magic_self, innocent_self, args, kwargs

class InnocentClass(object):
    magic_method = MagicMethod()

And now: InnocentClass().magic_method() will act like expected. The method will be bound with the innocent_self parameter to InnocentClass, and with the magic_self to the MagicMethod instance. Weird huh? It's like having 2 keywords this1 and this2 in languages like Java and C#. Magic like this allows frameworks to do stuff that would otherwise be much more verbose.

Again, I don't want to comment on the ethics of this stuff. I just wanted to show things that would be harder to do without an explicit self reference.

View more solutions

Comments

[Piotr Dobrogost]

I bet you would also be interested in knowing why you need to explicitly write self to access members - stackoverflow.com/questions/910020/…

[Raghuveer]

But it looks kinda a boiler plate though

[CrandellWS]

A bit confusing but worth understanding stackoverflow.com/a/31367197/1815624

[user3526905]

python-history.blogspot.in/2009/02/…

[Saurabh Kumar]

By convention, it should however be 'self' for instances or 'cls' where types are involved (mmmm metaclasses)

[Martin Beckett]

Although it would be nice to have a less cryptic error message when you forget it.

[user]

+1 for It's to minimize the difference between methods and functions. This should be accepted answer

[Marcin]

This also at the root of guido's much linked explanation.

[Nishant]

This also shows that in Python , when you do c.bar() first it checks instance for attributes , then it checks class attributes . So you can 'attach' a data or function (objects) to a Class anytime and expect to access in its instance (i.e dir(instance) will s how it ) . Not just when you "created" c instance . Its very dynamic .

[zachaysan]

I don't really buy it. Even in the cases where you need the parent class, you could still infer it upon execution. And equivalence between instance methods and class functions passed instances is silly; Ruby does just fine without them.

[Vedmant]

However when you call a method you don't have to pass object variable, doesn't it breaks the rule of explicitness? If to keep this zen, it have to be something like: object.method(object, param1, param2). Looks somehow inconsistent...

[Vedmant]

@ElmoVanKielmo I don't think so, you pass for example two parameters to function, object.method(param1, param2), but get three parameters def method(self, param1, param2). So first parameter passed implicitly, implicitly != explicitly.

[Vedmant]

It forces to put self as first param in every method, just extra text that doesn't make much sense as for me. Other languages work just fine with this.

[ElmoVanKielmo]

@Vedmant oh, come on. The concept is so simple and easy to understand. I don't even know why I'm getting into this purely academic discussion. Enormous amount of Python code was successfully developed and it works but now someone doesn't find it natural that the first argument of a method will hold a reference to the object on which the method is called. And there's one more reason for self to be there. In Python you can't use any symbol which is not available in the current scope (except for assignment) so self has to be exactly where it is.

[klaar]

When I consider your first example, I can do the same in Java: the inner class needs to call OuterClass.this to get the 'self' from the outer class, but you can still use this as a reference to itself; very similar to what you do here in Python. For me it wasn't harder to imagine this. Maybe it depends on one's proficiency in the language in question?

[vlad-ardelean]

But can you still refer to any scopes when you're inside a method of an anonymous class, which is defined inside an anonymous class, which is defined inside an anonymous implementation of interface Something, which is in turn defined inside yet another anonymous implementation of Something? In python you can of course refer to any of the scopes.

[klaar]

You are right, in Java you can only refer to the outer class by calling its explicit classname and use that to prefix this. Implicit references are impossibru in Java.

[vlad-ardelean]

I wonder if this would work though: In each scope (each method) have a local variable, that references the this result. For instance Object self1 = this; (either use Object, or something less generic). Then, if you have access to the variable in the higher scopes, you could have access to self1, self2, ...selfn. I think these should be declared final or something, but it might work.

[Simon]

"explicit is better than implicit" - Isn't the "style" of Python built around things being implicit? e.g. implicit data types, implicit function boundaries ( no { }'s), implicit variable scope... if global variables in modules are available in functions... why shouldn't that same logic/reasoning be applied to classes? Wouldn't the simplified rule just be "anything declared at a higher level is available at a lower level" as determined by indentation?

[Simon]

Allow me to answer my own comment... docs.python.org/3/tutorial/classes.html explains it nicely: a variable declared at the high level in a class is available to ALL instances of that class, so to me that's the reason why we need "self" (or whatever you decide to call it) to distinguish. I'd still argue it could be implemented in a simpler way: why not just have a variable "self" (with two underscores either side... i cant get that to display right here) fixed and available with each class to save people putting it in every function?

[Mohammad Mahdi KouchakYazdi]

am i right ? always the first parameter is a reference to the object.

[Mark]

@MMKY No, for example with @staticmethod it is not.

[RBV]

"You just have to remember that the first argument in a method definition..." I experimented with changing the word "self" to "kwyjibo" and it still worked. So as is often explained, it's not the word "self" that's important but the position of whatever occupies that space(?)

[Vahid Amiri]

"Explicit is better than implicit" Nonsense detected

[chbaker0]

"In Java and C++, this. can be deduced" This is very imprecise wording. The compiler isn't deducing anything. When it sees a variable name, it does a name lookup starting in the innermost scope and going up to the global or class scope.

[Toskan]

let's face it, it just is bad. There is no excuse for this. It's just an ugly relic but it's ok.

[Jonathan Benn]

JavaScript allows you to add methods to an object at run-time, and it doesn't require self in the function declaration (mind you, perhaps this is throwing stones from a glass house, since JavaScript has some pretty tricky this binding semantics)

[Qiulang]

Hi I am new to python (from java background) and I didn't quite flow what you said "how would you send messages to Objects when the messages themselves are objects ". Why is that a problem, can you elaborate?

[pankajdoharey]

@Qiulang Aah, in Object oriented programming calling methods on objects is equivalent to dispatching messages to Objects with or without a payload (parameters to your function). Methods internally would be represented as a block of code associated with an class/object and uses the implicit environment available to it through the object it is invoked against. But if your methods are objects they can exist independent of being associated to a class/object which begs the question if you invoke this method which environment would it run against?

[pankajdoharey]

Thus there must be a mechanism to provide an environment, self would mean the current environment at the point of execution but you could also provide another environment.

[mins]

The question is about the mandatory reference to the instance, not to the name used. Any modern language I know is able to relieve the developer form this chore. On the other hand Python is often used without defining any custom class at all (random example), and methods are just static and global (non OOP), not requiring 'self' or equivalent name, not even a main method. It seems to me superiority of mandatory 'self' has yet to be demonstrated.

[chainstair]

Great explanation. Finally one that totally made sense. Thanks man