The old ‘self’ controversy is making another appearance, stirred up by Bruce Eckel’s proposal to remove the requirement.
Let’s start with a quick summary of the controversy.
In Python, you have to declare “self” as a first parameter of all your methods:
[python]
class Foo():
def baz(self, x):
pass
[/python]
This is just a convention. The name “self” is not enforced by the compiler but it’s necessary to declare it as the first parameter of your method or Python will consider your method to be a function.
Python programmers feel strangely strongly about this convention and most of them don’t see this requirement as a problem (which is the reason why there is so much misunderstanding between both camps).
Interestingly, both sides often seem to miss the main reason why this controversy exists in the first place. It is *not* about typing less characters, it is *not* about having to prefix fields with that name (most people are fine with typing “self.f = 42”).
This is strictly about consistency, and James Watson summarized the problem very cleanly in his comment on Bruce Eckel’s proposal:
I think a lot of people are bothered by this because there is a disconnect between the number of arguments in the declaration and the number of arguments in the call.
In short: the method ‘baz’ above is declared with two parameters in the class but you invoke it with only one.
This problem goes beyond Python and OO philosophies: it’s the violation of a fundamental concept that has been the foundation of programming languages going decades back: when you declare a function with n parameters, you should invoke it with n parameters (slight exception if some of these parameters are optional, but this aspect is not germane to the discussion).
Guido took some time to explain why Bruce’s proposal cannot work. This is not the first time that explicit self has been under attack, and Guido has defended his design many times over the years.
I went over Guido’s explanation several times and to be honest, my eyes glazed over. My take away is that the reasons for the current design seem to be pretty serious and they dive deep into Python’s implementation.
And that’s mostly why I keep being bothered by explicit self: it seems to me it’s a design that is dictated more by the implementation than by the will to make this part of the language intuitive and in line with the estalbished science of computer languages.
C++, Java, C# and many other object-oriented languages support the concept of a self object available within the scope of the current method, and none of them require you to declare that parameter explicitly, so it can obviously be done. Arguing that it’s cleaner to require that parameter for the sake of readability when the real reason seems to be a limitation in the implementation strikes me as a bit dishonest.
To make matter worse (or better, if you’re into that sort of thing), Python has been adding dynamic features over these past years (such as adding a method inside a class outside the declaration of that class) that pretty much mean that the explicit self will never go away. I’m not convinced that these dynamic features were worth closing the door on the possibility of ever resolving the explicit self controversy, but the damage is done, and at this point, it’s pretty clear that Python will never lose its explicit self.
