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

>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?

I believe the original commenter was more referring to the lack of 'this' usage in Java.

So instead of having:

    this.x = y

People tend to do:

    x = y

Which isn't always the most clear that it's referencing an instance variable rather than a scoped variable, especially if you see it midway through a method.

A, alright then. I'd go with making this mandatory in that case.

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 [2] https://docs.python.org/3/library/dataclasses.html#post-init...

Java fields are declared in the same lexical scope as their use sites (except for inherited fields, but Python has the same magic in that case.)

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.

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

"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.

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.

To be pedantic "self" is not a keyword.

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.

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.