作者：豌豆花下貓

來(lái)源：Python貓

花下貓語(yǔ)：前兩天，我偶然在一個(gè)知識(shí)星球（劉欣老師的“碼農(nóng)翻身”）里看到一篇主題，劉老師表示 python 的類方法非要帶個(gè) self，而不像其它語(yǔ)言那樣隱藏起來(lái)，這讓人很不爽。我對(duì)此也有同感。在經(jīng)過(guò)群聊討論后，我獲知 Guido 曾經(jīng)專門撰文解釋過(guò)這個(gè)問(wèn)題。這篇文章并不好懂，我抽空先翻譯出來(lái)了，看看能收到什么回應(yīng)。如果可能的話，后續(xù)再另寫文章分析。

布魯斯·埃克爾（Bruce Eckel）發(fā)了篇博文[1]，提議從類方法的形參列表中刪除“self”。我將解釋為什么這個(gè)提議不能通過(guò)。（譯注：Bruce 是《Thinking in Java》、《Thinking in C++》等多本書籍的作者，也是個(gè) Python 開(kāi)發(fā)者。他的文章總結(jié)了當(dāng)年在巴西 Pycon 上的一次討論，主要觀點(diǎn)是在定義類方法時(shí)，形參中的“self”是多余的，而且由它引發(fā)的報(bào)錯(cuò)信息具有一定的誤導(dǎo)性。）

Bruce 的提議

Bruce 知道，我們需要一種方法來(lái)區(qū)分對(duì)實(shí)例變量的引用和對(duì)其它變量的引用，因此他建議將“self”設(shè)為關(guān)鍵字。

考慮一種典型的類，它有一個(gè)方法，例如：

class C:
   def meth(self, arg):
      self.val = arg
      return self.val

跟據(jù)Bruce 的提議，這將變?yōu)椋?

class C:
   def meth(arg):  # Look ma, no self!
      self.val = arg
      return self.val

這樣每個(gè)方法會(huì)節(jié)省 6 個(gè)字符。但我不覺(jué)得 Bruce 提出這個(gè)建議是為了減少打字。

我認(rèn)為他真正關(guān)心的是程序員（可能來(lái)自其它語(yǔ)言）所浪費(fèi)的時(shí)間，有時(shí)候似乎不需要指定“self”參數(shù)，而且他們偶爾忘記了要加（即使他們十分清楚——習(xí)慣是一種強(qiáng)大的力量）。確實(shí)，與忘記在實(shí)例變量或方法引用之前鍵入“self.”相比，從參數(shù)列表中省略“self”，往往會(huì)導(dǎo)致很模糊的錯(cuò)誤消息。

也許更糟糕的是（如 Bruce 所述），當(dāng)正確地聲明了方法，但是在調(diào)用時(shí)的參數(shù)數(shù)量不對(duì)，這時(shí)收到的錯(cuò)誤消息。如 Bruce 給出的以下示例：

Traceback (most recent call last):
File "classes.py", line 9, in
   obj.m2(1)
TypeError: m2() takes exactly 3 arguments (2 given)

我贊同它是令人困惑的，但是我寧愿去解決此錯(cuò)誤消息，而不是修改語(yǔ)言。

為什么 Bruce 的提議不可行

首先，讓我提出一些與 Bruce 的提議相反的典型論點(diǎn)。

這有一個(gè)很好的論據(jù)可以證明，在參數(shù)列表中使用顯式的“self”，可以增強(qiáng)以下兩種調(diào)用方法在理論上的等效性。假設(shè)“ foo”是“C”的一個(gè)實(shí)例：

foo.meth(arg) == C.meth(foo, arg)

（譯注：說(shuō)實(shí)話，我沒(méi)有理解這個(gè)例子的意思。以下僅是個(gè)人看法。在類的內(nèi)部定義方法時(shí)，可能會(huì)產(chǎn)生幾種不同的方法：實(shí)例方法、類方法和 靜態(tài)方法。它們的作用和行為是不同的，那么在定義和調(diào)用時(shí)怎么做區(qū)分呢？Python 約定了一種方式，即在定義時(shí)用第一個(gè)參數(shù)作區(qū)分：self 表示實(shí)例方法、cls或其它符號(hào) 表示類方法……三種方法都可以被類的實(shí)例調(diào)用，而且看起來(lái)一模一樣，如上例的等號(hào)左側(cè)那樣。這時(shí)候就要靠定義時(shí)賦予的參數(shù)來(lái)區(qū)分了，像上例等號(hào)右側(cè)，第一個(gè)參數(shù)是實(shí)例對(duì)象，表明此處是個(gè)實(shí)例方法。）

另一個(gè)論據(jù)是，在參數(shù)列表中使用顯式的“self”，將一個(gè)函數(shù)插入一個(gè)類，獲得動(dòng)態(tài)地修改一個(gè)類的能力，創(chuàng)建出相應(yīng)的一個(gè)類方法。

例如，我們可以創(chuàng)建一個(gè)與上面的“C”完全等效的類，如下所示：

# Define an empty class:
class C:
   pass

# Define a global function:
def meth(myself, arg):
   myself.val = arg
   return myself.val

# Poke the method into the class:
C.meth = meth

請(qǐng)注意，我將“self”參數(shù)重命名為“myself”，以強(qiáng)調(diào)（在語(yǔ)法上）我們不是在此處定義一個(gè)方法（譯注：類外部的是函數(shù)，即 function，類內(nèi)部的是方法，即 method）。

這樣之后，C 的實(shí)例就具有了一個(gè)“meth”方法，該方法有一個(gè)參數(shù)，且功能跟之前的完全一樣。對(duì)于在把方法插入類之前就創(chuàng)建的那些 C 的實(shí)例，它甚至也適用。

我想 Bruce 并不特別在意前述的等效性。我同意這只是理論上的重要。我能想到的唯一例外是舊式的調(diào)用超級(jí)方法的習(xí)語(yǔ)（idiom）。但是，這個(gè)習(xí)語(yǔ)很容易出錯(cuò)（正是由于需要顯式地傳遞"self"的原因），這就是為什么在 Python 3000中，我建議在所有情況下都使用"super()"的原因。

Bruce 可能會(huì)想到一種使第二個(gè)等效例子起作用的方法——在某些情況下，這種等效性真的很重要。我不知道 Bruce 花了多少時(shí)間思考如何實(shí)現(xiàn)他的提議，但是我想他正在考慮將一個(gè)名為“self”的額外形參自動(dòng)地添加到直接地在類內(nèi)部定義的所有方法的思路（我必須說(shuō)是“直接地”，以便那些嵌套在方法內(nèi)部的函數(shù)，能免于這種自動(dòng)操作）。這樣，可以使第一個(gè)等效例子保持等效。

但是，有一種情況我認(rèn)為 Bruce 不能在不向編譯器中添加某種 ESP 的情況下解決：裝飾器。我相信這是 Bruce 的提議的最終敗筆。

當(dāng)裝飾一個(gè)方法時(shí)，我們不知道是否要自動(dòng)地給它加一個(gè)“self”參數(shù)：裝飾器可以將函數(shù)變成一個(gè)靜態(tài)方法（沒(méi)有“self”）或一個(gè)類方法（有一個(gè)有趣的 self，它指向一個(gè)類而不是一個(gè)實(shí)例），或者可以做一些完全不同的事情（用純 Python 實(shí)現(xiàn)“ @classmethod”或“ @staticmethod”的裝飾器是繁瑣的）。除非知道裝飾器的用途，否則沒(méi)有其它辦法來(lái)確定是否要賦予正在定義的方法一個(gè)隱式的“self”參數(shù)。

我拒絕諸如特殊包裝的“@classmethod”和“@staticmethod”之類的黑科技。我也認(rèn)為除了自檢外，自動(dòng)地確定某個(gè)方法是類方法（class method）、實(shí)例方法（instance method）還是靜態(tài)方法（static method），這不是一個(gè)好主意（就像在 Bruce 的文章的評(píng)論中，有人建議的那樣）：這使得很難僅僅根據(jù)方法前的“def”，來(lái)決定應(yīng)該怎樣調(diào)用該方法。

（譯注：對(duì)于一個(gè)方法，在當(dāng)前的添加了相應(yīng)參數(shù)的情況下，可以簡(jiǎn)單地加裝飾器，區(qū)分它是哪種方法，調(diào)用時(shí)也容易區(qū)分調(diào)用；但是，如果沒(méi)有加參數(shù)，即使可以用神奇的自動(dòng)機(jī)制來(lái)區(qū)分出它是哪種方法，但在調(diào)用時(shí)，你不好確定該怎么調(diào)用）。

在評(píng)論中，我看到了一些非常極端的對(duì) Bruce 的提議的附和，但通常的代價(jià)是使得規(guī)則難以遵循，或者要求對(duì)語(yǔ)言進(jìn)行更深層的修改，這令我們極其難以接受它，特別是合入 Python 3.1。順便說(shuō)一句，對(duì)于 3.1，再次聲明我們的規(guī)則，新特性只有在保持向后兼容的情況下才是可接受的。

有一個(gè)似乎可行的建議（可以使它向后兼容）是把類中的

def foo(self, arg): ...

改成這樣的語(yǔ)法糖：

def self.foo(arg): ...

但我不認(rèn)同它把“self”變?yōu)楸Ａ糇郑╮eserved word），或者要求前綴必須是“self”。如果這樣做了，那對(duì)于類方法，很容易也出現(xiàn)這種情況：

@classmethod
def cls.foo(arg): ...

好了，相比于現(xiàn)狀，我并沒(méi)有更喜歡這個(gè)。但是相比于 Bruce 的提議或在他的博客評(píng)論區(qū)中提出的更極端的說(shuō)法，我認(rèn)為這個(gè)要好得多，而且它具有向后兼容的巨大優(yōu)勢(shì)，并且不需要很費(fèi)力，就可以寫成帶有參考實(shí)現(xiàn)的 PEP。（我想 Bruce 應(yīng)該會(huì)發(fā)現(xiàn)自己提案中的缺陷，如果他真的付出努力嘗試編寫可靠的 PEP 或者嘗試實(shí)現(xiàn)它。）

我可以繼續(xù)聊很多，但這是一個(gè)陽(yáng)光明媚的周日早晨，而我還有其它的計(jì)劃... :-)

作者：Guido van Rossum，寫于：2008.10.26

參考資料

[1] Bruce博文：http://www.artima.com/weblogs/viewpost.jsp?thread=239003

[2] Guido原文: https://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

——熱門課程推薦：

想學(xué)習(xí)PYTHON數(shù)據(jù)分析與金融數(shù)字化轉(zhuǎn)型精英訓(xùn)練營(yíng)，您可以點(diǎn)擊>>>“人才轉(zhuǎn)型”了解課程詳情；

想從事業(yè)務(wù)型數(shù)據(jù)分析師，您可以點(diǎn)擊>>>“數(shù)據(jù)分析師”了解課程詳情；

想從事大數(shù)據(jù)分析師，您可以點(diǎn)擊>>>“大數(shù)據(jù)就業(yè)”了解課程詳情；

想成為人工智能工程師，您可以點(diǎn)擊>>>“人工智能就業(yè)”了解課程詳情；

想了解Python數(shù)據(jù)分析，您可以點(diǎn)擊>>>“Python數(shù)據(jù)分析師”了解課程詳情；

想咨詢互聯(lián)網(wǎng)運(yùn)營(yíng)，你可以點(diǎn)擊>>>“互聯(lián)網(wǎng)運(yùn)營(yíng)就業(yè)班”了解課程詳情； 

想了解更多優(yōu)質(zhì)課程，請(qǐng)點(diǎn)擊>>>