14

As far as I know, self is just a very powerful convention and it's not really a reserved keyword in Python. Java and C# have this as a keyword. I really find it weird that they didn't make a reserved keyword for it in Python. Is there any reason behind this?

Terence Ponce
  • 9,123
  • 9
  • 31
  • 37
  • 2
    possible duplicate of [Why do you need explicitly have the "self" argument into a Python method?](http://stackoverflow.com/questions/68282/why-do-you-need-explicitly-have-the-self-argument-into-a-python-method) – Eli Bendersky Nov 09 '10 at 08:18
  • self is not a keyword because in Python self is explicit, unlike C#. So, this is really the same question as the one I linked to in the above comment. Please read it and others linked from it, for full enlightment – Eli Bendersky Nov 09 '10 at 08:18
  • 3
    The question is clearly different. Asking why self is nto a keyword deserves a different, and simpler answer, of why an explicit self. – jsbueno Nov 09 '10 at 14:09

3 Answers3

5

Because self is just a parameter to a function, like any other parameter. For example, the following call:

a = A()
a.x()

essentially gets converted to:

a = A()
A.x(a)

Not making self a reserved word has had the fortunate result as well that for class methods, you can rename the first parameter to something else (normally cls). And of course for static methods, the first parameter has no relationship to the instance it is called on e.g.:

class A:
    def method(self):
        pass

    @classmethod
    def class_method(cls):
        pass

    @staticmethod
    def static_method():
        pass

class B(A):
    pass

b = B()
b.method()        # self is b
b.class_method()  # cls is B
b.static_method() # no parameter passed
Tim Delaney
  • 5,535
  • 3
  • 24
  • 18
2

Guido van Rossum has blogged on why explicit self has to stay: http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

I believe that post provides some insight into the design decisions behind explicit self.

Arlaharen
  • 3,095
  • 29
  • 26
  • 6
    That's not what was asked. The question is not "why do I need to type self" but "why is self only a convention and not a keyword". It's possible to have `def foo(this):` if you really want to - I believe he's asking why calling it `self` is not forced on you. – Chris Morgan Nov 15 '10 at 11:19
  • this accepted answer does not actually answer the question – Tommy Mar 26 '20 at 15:01
0

Because a method is just a function who's first parameter is used to pass the object. You can write a method like this:

class Foo(object):
    pass

def setx(self, x):
    self.x = x

Foo.setx = setx

foo = Foo()
foo.setx(42)
print foo.x    # Prints 42.

Whatever the merit or otherwise of this philosophy, it does result in a more unified notion of functions and methods.

Marcelo Cantos
  • 181,030
  • 38
  • 327
  • 365
  • A method is not exactly just "a function": as your example shows, a method can be bound to an object instance, in which case it behaves like a function. Here, `foo.setx` is a *bound* method, which works like a function, but `Foo.setx` is a *method*, which does not work like a function. For instance, you cannot do `Foo.setx(instance_from_another_class, 42)`. – Eric O. Lebigot Nov 09 '10 at 08:40
  • 1
    EOL: When we write a emthod, it _is_ a function - and that is what coutns on the answer for this question. There would be no sense in making "self" a keyword since for python to be python, users still would have to be able to use any other variable name as the first parameter in a method. As for your concerns, when we make use of methods in a program, they are indeed not functions: they are converted to method objects at attribute retrieval time: http://metapython.blogspot.com/2010/11/python-instance-methods-how-are-they.html – jsbueno Nov 09 '10 at 14:07
  • @EOL: I guess it's a matter of perspective. Try this: `id(Foo.setx.func_code) == id(setx.func_code)`. While the rules about how you can call it may differ between `setx` and `Foo.setx`, they are both implemented as exactly the same function. The only attributes that differ are `__class__` and `__new__`. – Marcelo Cantos Nov 10 '10 at 01:12
  • @Marcelo: On the other hand, `id(Foo.setx) != id(setx)`, which shows that the `Foo.setx` *method* is different from the `setx()` *function*, despite the `Foo.setx = setx` assignment. – Eric O. Lebigot Nov 12 '10 at 11:54
  • @EOL: I don't dispute that. Something would have to be different in order for the same-class restriction to be possible. As I said, it's a matter of perspective. – Marcelo Cantos Nov 12 '10 at 22:39
  • @Marcello: Yeah, it's a matter of perspective. To add to an earlier comment of yours, `Foo.setx` and `setx` also differ in their `__call__` attribute (which, I guess, performs the type check on the first argument). – Eric O. Lebigot Nov 13 '10 at 10:30
  • @jsbueno: I found the Metaphython blog entry you pointed to very enlightening! Thank you so much! – Eric O. Lebigot Nov 13 '10 at 11:02