> an OO system that looks like it has been bolted in, compared to Ruby
I think the two languages just have different design philosophies. In Python, functions are fundamental and classes are built on top of them. In Ruby, objects are fundamental and functions (i.e. Procs etc) are themselves objects.
You could just as well claim that in Ruby, functions look like they have been bolted in. For example, you can’t call a Proc itself but need to call one of its methods.
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.
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.