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.

There's a fine line between "explicit is good because it means how things behave is obvious" and "explicit is bad because it means typing the same boilerplate over and over again."

Not saying Python fell on the wrong side of that line, just that it's an easy line to end up on the wrong side of.

Most things in a language are explicit design decisions. Doesn't automatically make them good decisions.

Actually Python is one of my favorite programming languages, probably the language with the closest mapping to how I naturally think about a problem. I really like it. But I'm also willing to admit it has some warts, as does any language.

> "Explicit is better than implicit"

Too bad Python breaks this "commandment" pretty much whenever it wants to.

To me, it makes sense for a class-based OO language with first-class functions and (unlike, e.g., Java) available direct external access to data members to do what Python does because it reinforces the distinction between function members and methods.

Perhaps more importantly, it makes even more sense in a language like Python where classes are (unlike many, especially statically-typed, class-based OO languages) first class objects to do what Python does, because of the relation of methods to classes. It also, to me. makes unbound/bound methods slightly more intuitive.

Now, I too was initially thrown by it because I'd used a bunch of OO languages that did it the other way first, and for quite a long time.

How would you describe OO languages which only have multimethods, then? Say, Dylan?

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

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

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.

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.