文末贈(zèng)書 | Python中5種不同的下劃線含義你都知道嗎？

前言

本文將介紹Python中單下劃線和雙下劃線("dunder")的各種含義和命名約定，名稱修飾(name mangling)的工作原理，以及它如何影響你自己的Python類。

單下劃線和雙下劃線 在Python變量和方法名稱中都各有其含義。有一些含義僅僅是依照約定，被視作是對(duì)程序員的提示 - 而有一些含義是由Python解釋器嚴(yán)格執(zhí)行的。

在本文中，我將討論以下五種下劃線模式和命名約定，以及它們?nèi)绾斡绊慞ython程序的行為：

• 單前導(dǎo)下劃線：_var
• 單末尾下劃線：var_
• 雙前導(dǎo)下劃線：__var
• 雙前導(dǎo)和末尾下劃線：__var__
• 單下劃線：_

在文章結(jié)尾處，你可以找到一個(gè)簡(jiǎn)短的速查表，總結(jié)了五種不同的下劃線命名約定及其含義，讓我們馬上開始！

1. 單前導(dǎo)下劃線 _var

當(dāng)涉及到變量和方法名稱時(shí)，單個(gè)下劃線前綴有一個(gè)約定俗成的含義。它是對(duì)程序員的一個(gè)提示：意味著Python社區(qū)一致認(rèn)為它應(yīng)該是什么意思，但程序的行為不受影響。

下劃線前綴的含義是告知其他程序員：以單個(gè)下劃線開頭的變量或方法僅供內(nèi)部使用。該約定在PEP 8中有定義。

這不是Python強(qiáng)制規(guī)定的。Python不像Java那樣在“私有”和“公共”變量之間有很強(qiáng)的區(qū)別。這就像有人提出了一個(gè)小小的下劃線警告標(biāo)志，說：

“

“嘿，這不是真的要成為類的公共接口的一部分。不去管它就好。“

”

看看下面的例子：

class?Test:
???def?__init__(self):
???????self.foo?=?11
???????self._bar?=?23

如果你實(shí)例化此類，并嘗試訪問在__init__構(gòu)造函數(shù)中定義的foo和_bar屬性，會(huì)發(fā)生什么情況？讓我們來看看：

>>>?t?=?Test()
>>>?t.foo
11
>>>?t._bar
23

你會(huì)看到_bar中的單個(gè)下劃線并沒有阻止我們“進(jìn)入”類并訪問該變量的值。

這是因?yàn)镻ython中的單個(gè)下劃線前綴僅僅是一個(gè)約定 - 至少相對(duì)于變量和方法名而言。

但是，前導(dǎo)下劃線的確會(huì)影響從模塊中導(dǎo)入名稱的方式。

假設(shè)你在一個(gè)名為my_module的模塊中有以下代碼：

#?This?is?my_module.py:

def?external_func():
???return?23

def?_internal_func():
???return?42

現(xiàn)在，如果使用通配符從模塊中導(dǎo)入所有名稱，則Python不會(huì)導(dǎo)入帶有前導(dǎo)下劃線的名稱（除非模塊定義了覆蓋此行為的__all__列表）：

>>>?from?my_module?import?*
>>>?external_func()
23
>>>?_internal_func()
NameError:?"name?'_internal_func'?is?not?defined"

順便說一下，應(yīng)該避免通配符導(dǎo)入，因?yàn)樗鼈兪姑Q空間中存在哪些名稱不清楚。為了清楚起見，堅(jiān)持常規(guī)導(dǎo)入更好。

與通配符導(dǎo)入不同，常規(guī)導(dǎo)入不受前導(dǎo)單個(gè)下劃線命名約定的影響：

>>>?import?my_module
>>>?my_module.external_func()
23
>>>?my_module._internal_func()
42

我知道這一點(diǎn)可能有點(diǎn)令人困惑。如果你遵循PEP 8推薦，避免通配符導(dǎo)入，那么你真正需要記住的只有這個(gè)：

“

單個(gè)下劃線是一個(gè)Python命名約定，表示這個(gè)名稱是供內(nèi)部使用的。它通常不由Python解釋器強(qiáng)制執(zhí)行，僅僅作為一種對(duì)程序員的提示。

”

2. 單末尾下劃線 var_

有時(shí)候，一個(gè)變量的最合適的名稱已經(jīng)被一個(gè)關(guān)鍵字所占用。因此，像class或def這樣的名稱不能用作Python中的變量名稱。在這種情況下，你可以附加一個(gè)下劃線來解決命名沖突：

>>>?def?make_object(name,?class):
SyntaxError:?"invalid?syntax"

>>>?def?make_object(name,?class_):
...????pass

總之，單個(gè)末尾下劃線（后綴）是一個(gè)約定，用來避免與Python關(guān)鍵字產(chǎn)生命名沖突。PEP 8解釋了這個(gè)約定。

3. 雙前導(dǎo)下劃線 __var

到目前為止，我們所涉及的所有命名模式的含義，來自于已達(dá)成共識(shí)的約定。而對(duì)于以雙下劃線開頭的Python類的屬性(包括變量和方法)，情況就有點(diǎn)不同了。

雙下劃線前綴會(huì)導(dǎo)致Python解釋器重寫屬性名稱，以避免子類中的命名沖突。

這也叫做名稱修飾(name mangling) - 解釋器更改變量的名稱，以便在類被擴(kuò)展的時(shí)候不容易產(chǎn)生沖突。

我知道這聽起來很抽象。因此，我組合了一個(gè)小小的代碼示例來予以說明：

class?Test:
???def?__init__(self):
???????self.foo?=?11
???????self._bar?=?23
???????self.__baz?=?23

讓我們用內(nèi)置的dir()函數(shù)來看看這個(gè)對(duì)象的屬性：

>>>?t?=?Test()
>>>?dir(t)
['_Test__baz',?'__class__',?'__delattr__',?'__dict__',?'__dir__',
'__doc__',?'__eq__',?'__format__',?'__ge__',?'__getattribute__',
'__gt__',?'__hash__',?'__init__',?'__le__',?'__lt__',?'__module__',
'__ne__',?'__new__',?'__reduce__',?'__reduce_ex__',?'__repr__',
'__setattr__',?'__sizeof__',?'__str__',?'__subclasshook__',
'__weakref__',?'_bar',?'foo']

以上是這個(gè)對(duì)象屬性的列表。讓我們來看看這個(gè)列表，并尋找我們的原始變量名稱foo，_bar和__baz ,我保證你會(huì)注意到一些有趣的變化。

• self.foo變量在屬性列表中顯示為未修改為foo。
• self._bar的行為方式相同 - 它以_bar的形式顯示在類上。就像我之前說過的，在這種情況下，前導(dǎo)下劃線僅僅是一個(gè)約定。給程序員一個(gè)提示而已。
• 然而，對(duì)于self.__baz而言，情況看起來有點(diǎn)不同。當(dāng)你在該列表中搜索__baz時(shí)，你會(huì)看不到有這個(gè)名字的變量。

__baz出什么情況了？

如果你仔細(xì)觀察，你會(huì)看到此對(duì)象上有一個(gè)名為_Test__baz的屬性。這就是Python解釋器所做的名稱修飾。它這樣做是為了防止變量在子類中被重寫。

讓我們創(chuàng)建另一個(gè)擴(kuò)展Test類的類，并嘗試重寫構(gòu)造函數(shù)中添加的現(xiàn)有屬性：

class?ExtendedTest(Test):
???def?__init__(self):
???????super().__init__()
???????self.foo?=?'overridden'
???????self._bar?=?'overridden'
???????self.__baz?=?'overridden'

現(xiàn)在，你認(rèn)為foo，_bar和__baz的值會(huì)出現(xiàn)在這個(gè)ExtendedTest類的實(shí)例上嗎？我們來看一看：

>>>?t2?=?ExtendedTest()
>>>?t2.foo
'overridden'
>>>?t2._bar
'overridden'
>>>?t2.__baz
AttributeError:?"'ExtendedTest'?object?has?no?attribute?'__baz'"

等一下，當(dāng)我們嘗試查看t2 .__ baz的值時(shí)，為什么我們會(huì)得到AttributeError？名稱修飾被再次觸發(fā)了！事實(shí)證明，這個(gè)對(duì)象甚至沒有__baz屬性：

>>>?dir(t2)
['_ExtendedTest__baz',?'_Test__baz',?'__class__',?'__delattr__',
'__dict__',?'__dir__',?'__doc__',?'__eq__',?'__format__',?'__ge__',
'__getattribute__',?'__gt__',?'__hash__',?'__init__',?'__le__',
'__lt__',?'__module__',?'__ne__',?'__new__',?'__reduce__',
'__reduce_ex__',?'__repr__',?'__setattr__',?'__sizeof__',?'__str__',
'__subclasshook__',?'__weakref__',?'_bar',?'foo',?'get_vars']

正如你可以看到__baz變成_ExtendedTest__baz以防止意外修改：

>>>?t2._ExtendedTest__baz
'overridden'

但原來的_Test__baz還在：

>>>?t2._Test__baz
42

雙下劃線名稱修飾對(duì)程序員是完全透明的。下面的例子證實(shí)了這一點(diǎn)：

class?ManglingTest:
???def?__init__(self):
???????self.__mangled?=?'hello'

???def?get_mangled(self):
???????return?self.__mangled

>>>?ManglingTest().get_mangled()
'hello'
>>>?ManglingTest().__mangled
AttributeError:?"'ManglingTest'?object?has?no?attribute?'__mangled'"

名稱修飾是否也適用于方法名稱？是的，也適用。名稱修飾會(huì)影響在一個(gè)類的上下文中，以兩個(gè)下劃線字符（"dunders"）開頭的所有名稱：

class?MangledMethod:
???def?__method(self):
???????return?42

???def?call_it(self):
???????return?self.__method()

>>>?MangledMethod().__method()
AttributeError:?"'MangledMethod'?object?has?no?attribute?'__method'"
>>>?MangledMethod().call_it()
42

這是另一個(gè)也許令人驚訝的運(yùn)用名稱修飾的例子：

_MangledGlobal__mangled?=?23

class?MangledGlobal:
???def?test(self):
???????return?__mangled

>>>?MangledGlobal().test()
23

在這個(gè)例子中，我聲明了一個(gè)名為_MangledGlobal__mangled的全局變量。然后我在名為MangledGlobal的類的上下文中訪問變量。由于名稱修飾，我能夠在類的test()方法內(nèi)，以__mangled來引用_MangledGlobal__mangled全局變量。

Python解釋器自動(dòng)將名稱__mangled擴(kuò)展為_MangledGlobal__mangled，因?yàn)樗詢蓚€(gè)下劃線字符開頭。這表明名稱修飾不是專門與類屬性關(guān)聯(lián)的。它適用于在類上下文中使用的兩個(gè)下劃線字符開頭的任何名稱。

有很多要吸收的內(nèi)容吧。

老實(shí)說，這些例子和解釋不是從我腦子里蹦出來的。我作了一些研究和加工才弄出來。我一直使用Python，有很多年了，但是像這樣的規(guī)則和特殊情況并不總是浮現(xiàn)在腦海里。

有時(shí)候程序員最重要的技能是“模式識(shí)別”，而且知道在哪里查閱信息。如果您在這一點(diǎn)上感到有點(diǎn)不知所措，請(qǐng)不要擔(dān)心。慢慢來，試試這篇文章中的一些例子。

讓這些概念完全沉浸下來，以便你能夠理解名稱修飾的總體思路，以及我向您展示的一些其他的行為。如果有一天你和它們不期而遇，你會(huì)知道在文檔中按什么來查。

4. 雙前導(dǎo)和雙末尾下劃線_var_

也許令人驚訝的是，如果一個(gè)名字同時(shí)以雙下劃線開始和結(jié)束，則不會(huì)應(yīng)用名稱修飾。由雙下劃線前綴和后綴包圍的變量不會(huì)被Python解釋器修改：

class?PrefixPostfixTest:
???def?__init__(self):
???????self.__bam__?=?42

>>>?PrefixPostfixTest().__bam__
42

但是，Python保留了有雙前導(dǎo)和雙末尾下劃線的名稱，用于特殊用途。這樣的例子有，init__對(duì)象構(gòu)造函數(shù)，或__call --- 它使得一個(gè)對(duì)象可以被調(diào)用。

這些dunder方法通常被稱為神奇方法 - 但Python社區(qū)中的許多人（包括我自己）都不喜歡這種方法。

最好避免在自己的程序中使用以雙下劃線（“dunders”）開頭和結(jié)尾的名稱，以避免與將來Python語言的變化產(chǎn)生沖突。

5.單下劃線 _

按照習(xí)慣，有時(shí)候單個(gè)獨(dú)立下劃線是用作一個(gè)名字，來表示某個(gè)變量是臨時(shí)的或無關(guān)緊要的。

例如，在下面的循環(huán)中，我們不需要訪問正在運(yùn)行的索引，我們可以使用“_”來表示它只是一個(gè)臨時(shí)值：

>>>?for?_?in?range(32):
...????print('Hello,?World.')

你也可以在拆分(unpacking)表達(dá)式中將單個(gè)下劃線用作“不關(guān)心的”變量，以忽略特定的值。同樣，這個(gè)含義只是“依照約定”，并不會(huì)在Python解釋器中觸發(fā)特殊的行為。單個(gè)下劃線僅僅是一個(gè)有效的變量名稱，會(huì)有這個(gè)用途而已。

在下面的代碼示例中，我將汽車元組拆分為單獨(dú)的變量，但我只對(duì)顏色和里程值感興趣。但是，為了使拆分表達(dá)式成功運(yùn)行，我需要將包含在元組中的所有值分配給變量。在這種情況下，“_”作為占位符變量可以派上用場(chǎng)：

>>>?car?=?('red',?'auto',?12,?3812.4)
>>>?color,?_,?_,?mileage?=?car

>>>?color
'red'
>>>?mileage
3812.4
>>>?_
12

除了用作臨時(shí)變量之外，“_”是大多數(shù)Python REPL中的一個(gè)特殊變量，它表示由解釋器評(píng)估的最近一個(gè)表達(dá)式的結(jié)果。

這樣就很方便了，比如你可以在一個(gè)解釋器會(huì)話中訪問先前計(jì)算的結(jié)果，或者，你是在動(dòng)態(tài)構(gòu)建多個(gè)對(duì)象并與它們交互，無需事先給這些對(duì)象分配名字：

>>>?20?+?3
23
>>>?_
23
>>>?print(_)
23

>>>?list()
[]
>>>?_.append(1)
>>>?_.append(2)
>>>?_.append(3)
>>>?_
[1,?2,?3]

小結(jié)

以下是一個(gè)簡(jiǎn)短的小結(jié)，即“速查表”，羅列了我在本文中談到的五種Python下劃線模式的含義：