4 ms·

I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy

I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.

zabzonk 7y ago
To be pedantic "self" is not a keyword.
- WorldMaker 7y ago
  Worse than that not being a keyword, `self` isn't special at all, it's a naming convention that can be freely broken. Python codebases using `this` instead of `self` exist. Codebases that mix the two depending on who wrote which method in a class exist. I believe I saw `it` used once somewhere as the name for that parameter. I'm sure there are codebases with even crazier horrors for first argument names in class methods out there in the depths of corporate machines.
timw4mail 7y ago
My experience with Python is a little lacking, but doesn't the self keyword mean the difference between an instance method, and a static method? Rust does the same thing - with self, it's an instance method, without, it's a static method.
- dfinninger 7y ago
  Python has an "@staticmethod" decorator you can put on a function inside of a class definition. Then you don't need to pass "self" as a first arg. https://www.geeksforgeeks.org/class-method-vs-static-method-python/ https://www.geeksforgeeks.org/class-method-vs-static-method-...
- int_19h 7y ago
  "self" is not a keyword in Python, just a convention. Any function inside a class declaration becomes an instance method, with its first argument becoming the explicit receiver. You have to use @staticmethod to prevent that (or @classmethod to get the class as the first argument, instead of the instance). Furthermore, this behavior is not parse-time, but runtime. The "def" statement that defines a function produces a plain function object, regardless of whether it's inside a class or not. Once the class finishes defining, the function is still a function - which is why C.f gives you a plain instance that can be called by passing "self" explicitly as an argument. However, Python allows objects to provide special behavior for themselves whenever they're retrieved via a member of some class - that is, when you write something like x.y, after y is retrieved from x, it gets the opportunity to peek at x, and substitute itself with something else. Function objects in Python (here I mean specifically the type of objects created with "def" and "lambda", not just any callable) use this feature to convert themselves to bound methods. So, when you say x.f, after retrieving f, f itself is asked if it wants to substitute something else in its place - and it returns a new callable object m, such that m(y) calls f(x, y). That's what makes x.f(y) work.
enragedcacti 7y ago
I personally really like the self keyword after spending some time reading code in Java where `this` is optional. Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I'm a fan of forcing devs to acknowledge when they are accessing or manipulating mutable object state. Separate from that, I think that would be a much bigger breaking change than you think. __setattr__ and __setattribute__ means that self.y doesn't necessarily refer to a traditional attribute so without self you could end up with either: 1. `x = y` where the expression `y` executes code or 2. `x = y` where `x = ???` and `x = self.y` where `x = self.__setattr__('y')`. That said, I do think the language could use something to reduce the size of __init__() since self.arg1 = arg1 self.arg2 = arg2 self.arg3 = arg3 ... can get pretty verbose
- dfinninger 7y ago
  To your last point, check out Dataclasses[1]. @dataclass class Foo: arg1: str arg2: int arg3: int = 5 # default value I use them a lot in my 3.7+ projects. It helps reduce the boilerplate for typical classes. (Where for me, typical classes are a 1:1 mapping of inputs to attributes) And if you need to compute some values at object initialization, then they have a __post_init__() hook you can use [2]. [1] https://docs.python.org/3/library/dataclasses.html https://docs.python.org/3/library/dataclasses.html [2] https://docs.python.org/3/library/dataclasses.html#post-init-processing https://docs.python.org/3/library/dataclasses.html#post-init...
- coldtea 7y ago
  >Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I don't understand this. Aside from people seeing an OOP for the first time in their life, are they getting confused about where "this" comes from? How would an implicit "self" a la "this" make it any less understandable where the data come from? How is passing self making "navigating an unfamiliar code base much easier"? Aside from total newbs who see an OO codebase with an implicit instance variable for the first time?
  - 7y ago
btown 7y ago
Self lets you do really cool things though. For instance, you can monkey-patch with `def override_method(arg_that_will_get_self, *args): pass; Class.method = override_method` after Class is defined. Python lets you have all the dynamism of Ruby without letting you go too crazy with DSLs - which is the perfect balance IMO.
dragonwriter 7y ago
Python doesn't have a self keyword, redundant or otherwise. In fact, that's a key difference between Python and many other class-based OO languages. I'm not sure whether that (and the associated need to make the receiver an explicit parameter—conventionally, though this is not required, named “self” in instance methods—in method definitions) is your problem, or if your problem is that (unlike some, but fewer than the previous difference, OO languages) you can't omit explicitly naming receiver in references to its own instance variables in an instance methods, making instance variable reference syntactically distinct from local variable references.

I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.

zabzonk 7y ago

To be pedantic "self" is not a keyword.

WorldMaker 7y ago
Worse than that not being a keyword, `self` isn't special at all, it's a naming convention that can be freely broken. Python codebases using `this` instead of `self` exist. Codebases that mix the two depending on who wrote which method in a class exist. I believe I saw `it` used once somewhere as the name for that parameter. I'm sure there are codebases with even crazier horrors for first argument names in class methods out there in the depths of corporate machines.

timw4mail 7y ago

My experience with Python is a little lacking, but doesn't the self keyword mean the difference between an instance method, and a static method? Rust does the same thing - with self, it's an instance method, without, it's a static method.

dfinninger 7y ago
Python has an "@staticmethod" decorator you can put on a function inside of a class definition. Then you don't need to pass "self" as a first arg. https://www.geeksforgeeks.org/class-method-vs-static-method-python/ https://www.geeksforgeeks.org/class-method-vs-static-method-...
int_19h 7y ago
"self" is not a keyword in Python, just a convention. Any function inside a class declaration becomes an instance method, with its first argument becoming the explicit receiver. You have to use @staticmethod to prevent that (or @classmethod to get the class as the first argument, instead of the instance). Furthermore, this behavior is not parse-time, but runtime. The "def" statement that defines a function produces a plain function object, regardless of whether it's inside a class or not. Once the class finishes defining, the function is still a function - which is why C.f gives you a plain instance that can be called by passing "self" explicitly as an argument. However, Python allows objects to provide special behavior for themselves whenever they're retrieved via a member of some class - that is, when you write something like x.y, after y is retrieved from x, it gets the opportunity to peek at x, and substitute itself with something else. Function objects in Python (here I mean specifically the type of objects created with "def" and "lambda", not just any callable) use this feature to convert themselves to bound methods. So, when you say x.f, after retrieving f, f itself is asked if it wants to substitute something else in its place - and it returns a new callable object m, such that m(y) calls f(x, y). That's what makes x.f(y) work.

enragedcacti 7y ago

I personally really like the self keyword after spending some time reading code in Java where `this` is optional. Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I'm a fan of forcing devs to acknowledge when they are accessing or manipulating mutable object state. Separate from that, I think that would be a much bigger breaking change than you think. __setattr__ and __setattribute__ means that self.y doesn't necessarily refer to a traditional attribute so without self you could end up with either: 1. `x = y` where the expression `y` executes code or 2. `x = y` where `x = ???` and `x = self.y` where `x = self.__setattr__('y')`. That said, I do think the language could use something to reduce the size of __init__() since self.arg1 = arg1 self.arg2 = arg2 self.arg3 = arg3 ... can get pretty verbose

dfinninger 7y ago
To your last point, check out Dataclasses[1]. @dataclass class Foo: arg1: str arg2: int arg3: int = 5 # default value I use them a lot in my 3.7+ projects. It helps reduce the boilerplate for typical classes. (Where for me, typical classes are a 1:1 mapping of inputs to attributes) And if you need to compute some values at object initialization, then they have a __post_init__() hook you can use [2]. [1] https://docs.python.org/3/library/dataclasses.html https://docs.python.org/3/library/dataclasses.html [2] https://docs.python.org/3/library/dataclasses.html#post-init-processing https://docs.python.org/3/library/dataclasses.html#post-init...
coldtea 7y ago
>Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I don't understand this. Aside from people seeing an OOP for the first time in their life, are they getting confused about where "this" comes from? How would an implicit "self" a la "this" make it any less understandable where the data come from? How is passing self making "navigating an unfamiliar code base much easier"? Aside from total newbs who see an OO codebase with an implicit instance variable for the first time?
- 7y ago

btown 7y ago

Self lets you do really cool things though. For instance, you can monkey-patch with `def override_method(arg_that_will_get_self, *args): pass; Class.method = override_method` after Class is defined. Python lets you have all the dynamism of Ruby without letting you go too crazy with DSLs - which is the perfect balance IMO.

dragonwriter 7y ago

Python doesn't have a self keyword, redundant or otherwise. In fact, that's a key difference between Python and many other class-based OO languages. I'm not sure whether that (and the associated need to make the receiver an explicit parameter—conventionally, though this is not required, named “self” in instance methods—in method definitions) is your problem, or if your problem is that (unlike some, but fewer than the previous difference, OO languages) you can't omit explicitly naming receiver in references to its own instance variables in an instance methods, making instance variable reference syntactically distinct from local variable references.