Why do you need "self." in Python to refer to instance variables?

Question

I have been programming into a number of languages like Java, Ruby, Haskell and Python. I have to switch between many languages per day due to different projects I work on. Now, the issue is I often forget to write self as the first parameter in the function definitions in Python same is with calling methods on the same object.

That said, I am quite amazed by this approach of Python. Basically we have to type more to get the things done, in the languages like Java and Ruby things are made simple by automatically referencing the variables in the current object.

My question is why is this self necessary? Is it purely a style choice, or is there a reason why Python can't let you omit self the way Java and C++ let you omit this?

• gnat: recommended reading: What is the problem with "Pros and Cons"?
• vivek: @gnat now only pros, and seriously its a good question which is bugging me since few days, please don't kill it by down voting.
• David Arno: This question has been more than thoroughly covered by stackoverflow.com/questions/2709821/….
• Dan Oberlam: My understanding is that it is based on the C-style of passing a pointer to a struct in as the first argument.
• Yash: Writing @staticmethod before method declaration, suppresses the error(just for info and also not recommended)

Answer 1

1) Why is self required as an explicit parameter in method signatures?

Because methods are functions and foo.bar(baz) is just syntactic sugar for bar(foo, baz). Classes are just dictionaries where some of the values are functions. (Constructors are also just functions, which is why Python doesn't need new) You can say that Python makes it explicit that objects are built from simpler components. This is in accordance with the "explicit is better than implicit"-philosophy.

In contrast, in Java objects really are magic and cannot be reduced to simpler components in the language. In Java (at least until Java 8) a function is always a method owned by an object, and this ownership cannot be changed due to the static nature of the language. Therefore there is no ambiguity about what this refers to, so it makes sense to have it implicitly defined.

JavaScript is an example of a language that has an implicit this like Java, but where functions can exist separately from objects like in Python. This leads to a lot of confusion about what this refers to when functions are passed around and called in different contexts. Many instinctively think this must refer to some intrinsic property of the function, while it is actually purely determined by the way the function is called. I believe having this as an explicit parameter like in Python would make this much less confusing.

Some other benefits of the explicit self-parameter:

• Decorators are just functions which wrap other functions. Since methods are just functions, decorators work just as fine on methods. If there were some kind of implicit self, decorators would not work transparently on methods.

• Classmethods and static methods do not take an instance parameter. Classmethods take a class as the first argument (typically called cls). The explicit self or cls parameters make it much clearer what is going on, and what you have access to in the method.

2) Why must instance variables always be qualified with"self.?

In Java, you don't need to prefix member variables with "this.", but in Python "self." is always required. The reason is that Python does not have an explicit syntax for declaring variables, so there would be no way to tell if x = 7 is supposed to declare a new local variable or assign to a member variable. Specifying self. solves this ambiguity.

• Jan Hudec: Implicit member variable reference (without self., like Java) is fundamentally incompatible with the scoping rules and when you need to be explicit there, being implicit about the parameter does not make all that much sense any more.
• JacquesB: @JanHudec: Good, point. I have added it to the answer.

Answer 2

There is a rather simple reason that AFAIK hasn't really been touched upon in the cross-site duplicate, nor here: Python started out as a procedural language. It was based on ABC, also a procedural language.

Object-Orientation was added later, and when it was added, Guido van Rossum wanted to add the minimal amount of features possible, in order to keep the design of Python simple. Python already had dicts and functions, so why add something entirely new to the language, when an object can simply be a dict of slots and a class can simply be a dict of functions? A method can be interpreted as a partially-applied function that closes over a single distinguished argument. And that's precisely how methods are implemented in Python: they aren't. They are just functions which receive an extra distinguished argument.

• JacquesB: I believe Python supported OO and had classes and inheritance from the very first released version. At least this is what wikipedia tells me. But van Rossums process in initially designing the language might have been as you describe.
• Jörg W Mittag: "Believe it or not, classes were added late during Python’s first year of development at CWI"
• JacquesB: Thank you for the link, this is really interesting reading.

Answer 3

Here are my conclusions based on above answers and reading the Guido's own rambling on this topic:

The big idea

Functions are the important building blocks in Python (or we should say the only one), in fact we are kind of emulating OOP by using functions.

Given that a class is nothing but a dictionary of functions hence, we can attach any function to any class at run time. Basically it is because of this need to toss the functions around at run time we can do stuffs like Monkey Patching. Here the self parameter supporting the parametric Polymorphism.

• user53019: Self-answered questions are encouraged when your answer is a high quality answer. When I compare your answer here to the other answers, I'm left wondering why you felt like you needed to add this. The other answers go into more depth and add more detail than what your answer does.
• vivek: @GlenH7 the answer was just for my reference because every time I can't come and read everyone's answer again and again. Regarding quality, tell me if any bit of information is misleading. Anyways I generally wait 2-3 days to accept any answer.
• vivek: Down voting is becoming cheap currency and everyone here is spending it with both hands without knowing its meaning. Do you realize if someone comes here see this answer down voted would assume its wrong!