python是對面向對象編程友好的語言嗎？有沒有改進空間？

比如定義所有的成員函數都要加self參數，在類內部調用成員函數和訪問成員變數都需要加self.的前綴，沒有定義一目了然的訪問許可權修飾符(如public，private，protected)，子類構造函數不默認調用父類構造函數等等。感覺上python從語法上還是更鼓勵面向過程編程。我現在每次用Python寫類特別是靜態成員很多的類都覺得很蛋疼，寫著寫著就想把所有靜態成員函數和靜態成員變數都直接扔到模塊的全局空間裡面。

補充一下，我之所以會產生python在面向對象編程方面需要改進的感覺，一個原因是，過去我在的一家公司在移動設備上使用C語言進行開發，為了引入面向對象編程，採用了一種叫做OOC的機制來模擬類和對象（因為當時移動設備的計算能力和內存空間都還很低，大概還有一些硬體相關編譯器的原因，沒有直接引入C++)，和python的self簡直一模一樣，你們感受一下：

定義某個類就是定義一個struct，比如名字叫ClassA，所有A的成員函數（邏輯上的類成員函數，在語法上其實都是普通的C函數）都寫在一個ClassA.h和ClassA.c裡面，定義形式為：

ClassA__func(A a, param1, param2...)

在使用的時候就是

ClassA a;

ClassA__func(a, p1, p2...);

就當做是a.func(p1, p2...)來用了。

當時寫的時候感覺很蛋疼，但是也沒有辦法，畢竟是拿C模擬出來的面向對象，不像C++在設計之初就是支持面向對象的。所以當我看到python的self語法的時候就不能理解了，明明說是支持面向對象的語言，是怎麼想到設計成那麼噁心的語法的？？？倒更像是本來沒打算支持面向對象，解釋器寫到一半為了勉強支持面向對象而把語法改成這個樣子的。

我不否認python是一門很便捷、生產力水平很高的語言，但是感覺它更鼓勵面向過程編程而不是面向對象。

棉花糖吃多了壞牙，語法糖吃多了壞口味……

就因為需要顯式傳遞this指針，就不是OO了？對於非虛的成員函數，基本上C++的編譯器就是把a.func(p1, p2...)給翻譯成了ClassA__func(a, p1, p2...);編譯器干這個就叫OO，自己干就叫過程式？這根本就是忽視了OO的精粹，只是根據語法糖的甜度來評價編程語言呀。

OO有三好：封裝，繼承，和多態。Python對這三個本質都有不錯的支持，所以本質上講，Python是OO友好的語言。當然有改進的空間，但我個人也不覺得應該過度糖化。語法多糖，甜到憂傷……

Python是OO語言。

你說的這些「缺陷」，根植於python設計者的價值觀，好不好見仁見智。OO的實現在語言間有差異，這是常態，所以不需要太糾結某一個實現細節，我們認為public/private/protected是OO是因為最開始接觸的資料上用的語言有這樣的實現，他們不是OO的必然。

&>&>&> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit. *
Simple is better than complex. *
Complex is better than complicated.
Flat is better than nested. *
Sparse is better than dense.
Readability counts.
Special cases aren"t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you"re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it"s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let"s do more of those!