3 ms·

> I personally wish they would just make `self` implicit Hell no. Go use Java if you want that. If you find typing self is making you more work then you're not

> I personally wish they would just make `self` implicit Hell no. Go use Java if you want that. If you find typing self is making you more work then you're not using classes correctly. Write functions and use classes if you need them.

meowface 8y ago
edit: To be clear, I mean making `self` implicit in the method signature - not implicit in the method body like the way Java does it. It's a very minor and aesthetic/cosmetic thing. No, I don't write classes for everything. I write functions for things that should be functions and classes for things that should be classes. But when I do write classes, it's annoying to remember to write `self` in the method signature, annoying to get exceptions because I forgot to add it, annoying to see it since it's just that tiny bit of additional redundant line noise when I just want to quickly glance at a method signature. And literally no other OO language does this that I'm aware of; even ones that are generally way less dynamic than Python. But as I said, I do understand how it came about and why it is the way it is. But on the other hand, it was the exact same story for `super()`, and they did resolve that with "magic". The "magic" floodgates have also opened up a bit more with string interpolation added [1]. So now I think a more reasonable case can be made for making `self` optional. If they could do it for `super()`, they can do it for `self`. It doesn't annoy me that much, though, and I still plan to use Python for a long time even if it's never changed. [1] https://www.python.org/dev/peps/pep-0498/ https://www.python.org/dev/peps/pep-0498/
- Waterluvian 8y ago
  Do you mean remove self from the method signature or altogether? I think the latter is fundamentally impossible. There would be name collisions and it would be horribly ambiguous. I assume you're suggesting the former. I can see it being plausible. I'm not sure I have a really clear case against it. I do really like that things are explicit. There's no magical place "self" emerges from. I hate this about some other languages, like JavaScript's 'attributes' collection that magically exists in a function context. Being able to juggle binded and unbinded functions is nice. The explicit self or cls kind of forces you to declare what the intent of your function is. Not super clear. But the ship has sailed on that issue. Not sure it could be changed in a non breaking way.
  - meowface 8y ago
    Ah sorry, I meant from the method signature. I wouldn't like the totally implicit `self` / `this` found in Java. >Being able to juggle binded and unbinded functions is nice. The explicit self or cls kind of forces you to declare what the intent of your function is. Sure, but we can already do that with the @classmethod decorator. They could just make it so `cls` is a variable that can be accessed from any method. If it's a class method, `cls = self`, otherwise, `cls = self.__class__`.
- another-cuppa 8y ago
  OK, implicit self in the signatures is probably OK. I don't find it a problem personally because I use snippets to generate functions and methods etc. while I write them.
  - meowface 8y ago
    Despite programming for many years and using VS Code for about 6 months, I've still never used snippets even once. I should give them a shot.
- duckerude 8y ago
  This has a lot of edge cases. Currently, `self` is a strong convention, but not more than that. You can write code like this: class Foo: def __init__(this, x, y=3): this.x = x this.y = y Would a self-optional version of Python be able to recognize that it shouldn't make that method implicit? Breaking that code may or may not be acceptable, I don't know how common it is. Would it still be possible to access methods on classes as if they're ordinary functions? e.g. >>> str.casefold('Foo') 'foo' It's occasionally useful for higher-order functions like map, or to call methods from different classes. Would accessing methods like that return a special unbound method with an extra argument? What's the behavior of functions that were defined elsewhere and attached to the class later? def double(n): return 2*n class MySpecialInt(int): double = double >>> MySpecialInt(10).double() 20 Do they behave the old way? Do they behave the new way? Does it depend on their own parameter list? How are decorators handled? def printme(func): def inner(*args, **kwargs): print(args, kwargs) return func(*args, **kwargs) return inner class Foo: @printme def bar(x, y): ... Can `inner` access self? Can `bar/func` access self? `printme` certainly can't access self, because it doesn't exist yet when it runs. It might be possible to make this change, but not without breaking compatibility. Argumentless super() adds behavior to something that used to throw a TypeError, which is much easier. As a sidenote, I think super() is much more magical than string interpolation: f"foo: {foo!r}" can be rewritten to "foo: {!r}".format(foo), but rewriting super() requires looking at the surrounding code.

meowface 8y ago

edit: To be clear, I mean making `self` implicit in the method signature - not implicit in the method body like the way Java does it. It's a very minor and aesthetic/cosmetic thing. No, I don't write classes for everything. I write functions for things that should be functions and classes for things that should be classes. But when I do write classes, it's annoying to remember to write `self` in the method signature, annoying to get exceptions because I forgot to add it, annoying to see it since it's just that tiny bit of additional redundant line noise when I just want to quickly glance at a method signature. And literally no other OO language does this that I'm aware of; even ones that are generally way less dynamic than Python. But as I said, I do understand how it came about and why it is the way it is. But on the other hand, it was the exact same story for `super()`, and they did resolve that with "magic". The "magic" floodgates have also opened up a bit more with string interpolation added [1]. So now I think a more reasonable case can be made for making `self` optional. If they could do it for `super()`, they can do it for `self`. It doesn't annoy me that much, though, and I still plan to use Python for a long time even if it's never changed. [1] https://www.python.org/dev/peps/pep-0498/ https://www.python.org/dev/peps/pep-0498/

Waterluvian 8y ago
Do you mean remove self from the method signature or altogether? I think the latter is fundamentally impossible. There would be name collisions and it would be horribly ambiguous. I assume you're suggesting the former. I can see it being plausible. I'm not sure I have a really clear case against it. I do really like that things are explicit. There's no magical place "self" emerges from. I hate this about some other languages, like JavaScript's 'attributes' collection that magically exists in a function context. Being able to juggle binded and unbinded functions is nice. The explicit self or cls kind of forces you to declare what the intent of your function is. Not super clear. But the ship has sailed on that issue. Not sure it could be changed in a non breaking way.
- meowface 8y ago
  Ah sorry, I meant from the method signature. I wouldn't like the totally implicit `self` / `this` found in Java. >Being able to juggle binded and unbinded functions is nice. The explicit self or cls kind of forces you to declare what the intent of your function is. Sure, but we can already do that with the @classmethod decorator. They could just make it so `cls` is a variable that can be accessed from any method. If it's a class method, `cls = self`, otherwise, `cls = self.__class__`.
another-cuppa 8y ago
OK, implicit self in the signatures is probably OK. I don't find it a problem personally because I use snippets to generate functions and methods etc. while I write them.
- meowface 8y ago
  Despite programming for many years and using VS Code for about 6 months, I've still never used snippets even once. I should give them a shot.
duckerude 8y ago
This has a lot of edge cases. Currently, `self` is a strong convention, but not more than that. You can write code like this: class Foo: def __init__(this, x, y=3): this.x = x this.y = y Would a self-optional version of Python be able to recognize that it shouldn't make that method implicit? Breaking that code may or may not be acceptable, I don't know how common it is. Would it still be possible to access methods on classes as if they're ordinary functions? e.g. >>> str.casefold('Foo') 'foo' It's occasionally useful for higher-order functions like map, or to call methods from different classes. Would accessing methods like that return a special unbound method with an extra argument? What's the behavior of functions that were defined elsewhere and attached to the class later? def double(n): return 2*n class MySpecialInt(int): double = double >>> MySpecialInt(10).double() 20 Do they behave the old way? Do they behave the new way? Does it depend on their own parameter list? How are decorators handled? def printme(func): def inner(*args, **kwargs): print(args, kwargs) return func(*args, **kwargs) return inner class Foo: @printme def bar(x, y): ... Can `inner` access self? Can `bar/func` access self? `printme` certainly can't access self, because it doesn't exist yet when it runs. It might be possible to make this change, but not without breaking compatibility. Argumentless super() adds behavior to something that used to throw a TypeError, which is much easier. As a sidenote, I think super() is much more magical than string interpolation: f"foo: {foo!r}" can be rewritten to "foo: {!r}".format(foo), but rewriting super() requires looking at the surrounding code.