Comment by meowface | Hacker News Reader

Comment by meowface | Hacker News Reader

Parent Full thread

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/

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.

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.

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__`.

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.

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.

Reply on news.ycombinator.com