Comment by pmontra
I agree. Python was designed in 1989 and it looks like the OOP we were doing in C (without the ++) back at the time. Objects were a struct with data and function pointers and we were passing them around as pointers. Python has self, explicit in function definition and implicit in function calls, and that self is really like the pointer to the struct. By the way, OO languages from the 90s (e.g. Java and Ruby) were designed to always hide that self, both in method definition and method call. They use it when there is a need to tell the difference between instance attributes and local variables with the same name.
Maybe the explicit self was there to make C programmers feel at home. Functions as fundamental building blocks of the language also make C programmers feel at home. Developers got more familiar with OOP by mid 90s so the new languages could jump from functions-first to objects-first.
I think Python's OO is a bit suboptimal even if the goal was to have method-centric OOP like in C with classes. For example, mechanisms to hide information, a fundamental part of the OO paradigm, are hacky. You need to use name mangling.
Same applies to FP, a few things are weird and crippled. IMHO, the net result is that Python code tends to look longer and much more algorithmic than in Ruby, Smalltalk or various Lisps, where the language favors lots of little functions that call each other.
Things are changing a bit, though. For example, pattern matching (PEP 622) brings some conciseness. Fixing those other issues would be great.