5 ms·

I’ve seen a lot of people taking issue with the self argument. Am I crazy to actually love it as a feature? I pulled out a lot of my hairs when I first started

I’ve seen a lot of people taking issue with the self argument. Am I crazy to actually love it as a feature? I pulled out a lot of my hairs when I first started OOP (Java) trying to gork `this`, and I remember myself thinking “why didn’t everybody just do this” when I saw how Python declare methods. And I still think that’s a good idea now. So much easier to keep my sanity than using JavaScript’s bind.

gowld 7y ago
What's weird is that it's half baked def foo(self): instead of a more logical: def self.foo(): to match the calling syntax.
- duahncjak 7y ago
  Wow, this is a lot more intuitive. gowld for BDFL!
- keypusher 7y ago
  I don't think you understand what is actually going on under the hood here, at all. Methods are member functions of a class, and must be invoked on an object. someInstance.foo() When invoking a method from within the class, you still need a reference to the object the method will be invoked on. In python, the reference is passed implicitly as the first argument, and usually called self. That has nothing to do with the method name or signature itself, and calling the method self.foo() would result in calling it like someInstance.self.foo() for cases when you aren't referencing the function from within the class, which would be even more confusing.
  - biggestdecision 7y ago
    The syntax of a language is an abstraction over what is actually going on under the hood. There's no reason python couldn't have designed their OOP abstraction more elegantly.
    - joshuamorton 7y ago
      Why is self.foo more elegant? It's very rare that you'll call a given method as self.foo, and there's a slew of complications that come with such a syntax (the declaration grammar is more complex, `self` is now special, etc.) It's true that languages are abstractions, but not all abstractions are useful.
      - int_19h 7y ago
        It doesn't have to treat "self" as a special keyword - it just has to desugar "foo.bar(x, y)" into "bar(foo, x, y)". There are some other languages that do that - e.g. in F#, you write: member this.foo(x, y) = ... Again, "this" is just an identifier here, and doesn't have any special meaning. It's more elegant firstly because it follow use, and secondly because it means that "def foo(x)" has the same meaning both inside and outside of a class declaration - it's just a function, and there's nothing special about its first argument. As it is, we need stuff like @staticmethod and @classmethod. It's especially annoying when you have class attributes that happen to reference a function, because conversion from functions to methods is a runtime thing - so you have to remember to wrap those in staticmethod() as well.
        dragonwriter 7y ago
        > As it is, we need stuff like @staticmethod and @classmethod You would need those even with your suggestion (except you could drop @staticmethod if you add another layer of magic so that methods declared without an leading identifier were assumes static; you'd still need @classmethod some equivalent mechanism to distinguish which non-static methods were class vs instance methods.)
        int_19h 7y ago
        My suggestion implied removing the descriptor-based "magic" on regular functions that make them behave as methods when accessed using dot-member syntax, and instead making the "def self.foo" syntax produce a special kind of function that would have that behavior. @staticmethod today basically just suppresses that special behavior on regular functions, so it wouldn't be needed in this case. But yeah, we'd still need @classmethod.
- Doxin 7y ago
  The thing is that that doesn't really match the calling syntax, it matches the syntactic sugar for the calling syntax. Whenever you do thing_instance.foo(bar, baz) you're secretly calling Thing.foo(thing_instance, bar, baz) Which succinctly explains where the self argument comes from.

gowld 7y ago

What's weird is that it's half baked def foo(self): instead of a more logical: def self.foo(): to match the calling syntax.

duahncjak 7y ago
Wow, this is a lot more intuitive. gowld for BDFL!
keypusher 7y ago
I don't think you understand what is actually going on under the hood here, at all. Methods are member functions of a class, and must be invoked on an object. someInstance.foo() When invoking a method from within the class, you still need a reference to the object the method will be invoked on. In python, the reference is passed implicitly as the first argument, and usually called self. That has nothing to do with the method name or signature itself, and calling the method self.foo() would result in calling it like someInstance.self.foo() for cases when you aren't referencing the function from within the class, which would be even more confusing.
- biggestdecision 7y ago
  The syntax of a language is an abstraction over what is actually going on under the hood. There's no reason python couldn't have designed their OOP abstraction more elegantly.
  - joshuamorton 7y ago
    Why is self.foo more elegant? It's very rare that you'll call a given method as self.foo, and there's a slew of complications that come with such a syntax (the declaration grammar is more complex, `self` is now special, etc.) It's true that languages are abstractions, but not all abstractions are useful.
    - int_19h 7y ago
      It doesn't have to treat "self" as a special keyword - it just has to desugar "foo.bar(x, y)" into "bar(foo, x, y)". There are some other languages that do that - e.g. in F#, you write: member this.foo(x, y) = ... Again, "this" is just an identifier here, and doesn't have any special meaning. It's more elegant firstly because it follow use, and secondly because it means that "def foo(x)" has the same meaning both inside and outside of a class declaration - it's just a function, and there's nothing special about its first argument. As it is, we need stuff like @staticmethod and @classmethod. It's especially annoying when you have class attributes that happen to reference a function, because conversion from functions to methods is a runtime thing - so you have to remember to wrap those in staticmethod() as well.
      - dragonwriter 7y ago
        > As it is, we need stuff like @staticmethod and @classmethod You would need those even with your suggestion (except you could drop @staticmethod if you add another layer of magic so that methods declared without an leading identifier were assumes static; you'd still need @classmethod some equivalent mechanism to distinguish which non-static methods were class vs instance methods.)
        int_19h 7y ago
        My suggestion implied removing the descriptor-based "magic" on regular functions that make them behave as methods when accessed using dot-member syntax, and instead making the "def self.foo" syntax produce a special kind of function that would have that behavior. @staticmethod today basically just suppresses that special behavior on regular functions, so it wouldn't be needed in this case. But yeah, we'd still need @classmethod.
Doxin 7y ago
The thing is that that doesn't really match the calling syntax, it matches the syntactic sugar for the calling syntax. Whenever you do thing_instance.foo(bar, baz) you're secretly calling Thing.foo(thing_instance, bar, baz) Which succinctly explains where the self argument comes from.