加入人工智能技術(shù)社區(qū)! 源 | Python程序員 本文介紹了Python中單下劃線和雙下劃線('dunder')的各種含義和命名約定,名稱修飾(name mangling)的工作原理,以及它如何影響你自己的Python類。 單下劃線和雙下劃線在Python變量和方法名稱中都各有其含義。有一些含義僅僅是依照約定,被視作是對程序員的提示 - 而有一些含義是由Python解釋器嚴格執(zhí)行的。 如果你想知道“Python變量和方法名稱中單下劃線和雙下劃線的含義是什么?”,我會盡我所能在這里為你解答。 在本文中,我將討論以下五種下劃線模式和命名約定,以及它們?nèi)绾斡绊慞ython程序的行為:
在文章結(jié)尾處,你可以找到一個簡短的“速查表”,總結(jié)了五種不同的下劃線命名約定及其含義,以及一個簡短的視頻教程,可讓你親身體驗它們的行為。 讓我們馬上開始! 1. 單前導(dǎo)下劃線 _var當(dāng)涉及到變量和方法名稱時,單個下劃線前綴有一個約定俗成的含義。 它是對程序員的一個提示 - 意味著Python社區(qū)一致認為它應(yīng)該是什么意思,但程序的行為不受影響。 下劃線前綴的含義是告知其他程序員:以單個下劃線開頭的變量或方法僅供內(nèi)部使用。 該約定在PEP 8中有定義。 這不是Python強制規(guī)定的。 Python不像Java那樣在“私有”和“公共”變量之間有很強的區(qū)別。 這就像有人提出了一個小小的下劃線警告標志,說:
看看下面的例子: class Test: 如果你實例化此類,并嘗試訪問在__init__構(gòu)造函數(shù)中定義的foo和_bar屬性,會發(fā)生什么情況? 讓我們來看看: >> t = Test() 你會看到_bar中的單個下劃線并沒有阻止我們“進入”類并訪問該變量的值。 這是因為Python中的單個下劃線前綴僅僅是一個約定 - 至少相對于變量和方法名而言。 但是,前導(dǎo)下劃線的確會影響從模塊中導(dǎo)入名稱的方式。 假設(shè)你在一個名為my_module的模塊中有以下代碼: # This is my_module.py: 現(xiàn)在,如果使用通配符從模塊中導(dǎo)入所有名稱,則Python不會導(dǎo)入帶有前導(dǎo)下劃線的名稱(除非模塊定義了覆蓋此行為的__all__列表): from my_module import * 順便說一下,應(yīng)該避免通配符導(dǎo)入,因為它們使名稱空間中存在哪些名稱不清楚。 為了清楚起見,堅持常規(guī)導(dǎo)入更好。 與通配符導(dǎo)入不同,常規(guī)導(dǎo)入不受前導(dǎo)單個下劃線命名約定的影響: >> import my_module 我知道這一點可能有點令人困惑。 如果你遵循PEP 8推薦,避免通配符導(dǎo)入,那么你真正需要記住的只有這個:
2. 單末尾下劃線 var_有時候,一個變量的最合適的名稱已經(jīng)被一個關(guān)鍵字所占用。 因此,像class或def這樣的名稱不能用作Python中的變量名稱。 在這種情況下,你可以附加一個下劃線來解決命名沖突: def make_object(name, class): 總之,單個末尾下劃線(后綴)是一個約定,用來避免與Python關(guān)鍵字產(chǎn)生命名沖突。 PEP 8解釋了這個約定。 3. 雙前導(dǎo)下劃線 __var到目前為止,我們所涉及的所有命名模式的含義,來自于已達成共識的約定。 而對于以雙下劃線開頭的Python類的屬性(包括變量和方法),情況就有點不同了。 雙下劃線前綴會導(dǎo)致Python解釋器重寫屬性名稱,以避免子類中的命名沖突。 這也叫做名稱修飾(name mangling) - 解釋器更改變量的名稱,以便在類被擴展的時候不容易產(chǎn)生沖突。 我知道這聽起來很抽象。 因此,我組合了一個小小的代碼示例來予以說明: class Test: 讓我們用內(nèi)置的dir()函數(shù)來看看這個對象的屬性:
以上是這個對象屬性的列表。 讓我們來看看這個列表,并尋找我們的原始變量名稱foo,_bar和__baz - 我保證你會注意到一些有趣的變化。
__baz出什么情況了? 如果你仔細觀察,你會看到此對象上有一個名為_Test__baz的屬性。 這就是Python解釋器所做的名稱修飾。 它這樣做是為了防止變量在子類中被重寫。 讓我們創(chuàng)建另一個擴展Test類的類,并嘗試重寫構(gòu)造函數(shù)中添加的現(xiàn)有屬性: class ExtendedTest(Test): 現(xiàn)在,你認為foo,_bar和__baz的值會出現(xiàn)在這個ExtendedTest類的實例上嗎? 我們來看一看:
等一下,當(dāng)我們嘗試查看t2 .__ baz的值時,為什么我們會得到AttributeError? 名稱修飾被再次觸發(fā)了! 事實證明,這個對象甚至沒有__baz屬性:
正如你可以看到__baz變成_ExtendedTest__baz以防止意外修改:
但原來的_Test__baz還在: >> t2._Test__baz 雙下劃線名稱修飾對程序員是完全透明的。 下面的例子證實了這一點: class ManglingTest: 名稱修飾是否也適用于方法名稱? 是的,也適用。名稱修飾會影響在一個類的上下文中,以兩個下劃線字符('dunders')開頭的所有名稱: class MangledMethod: 這是另一個也許令人驚訝的運用名稱修飾的例子: _MangledGlobal__mangled = 23 在這個例子中,我聲明了一個名為_MangledGlobal__mangled的全局變量。然后我在名為MangledGlobal的類的上下文中訪問變量。由于名稱修飾,我能夠在類的test()方法內(nèi),以__mangled來引用_MangledGlobal__mangled全局變量。 4. 雙前導(dǎo)和雙末尾下劃線 _var_也許令人驚訝的是,如果一個名字同時以雙下劃線開始和結(jié)束,則不會應(yīng)用名稱修飾。 由雙下劃線前綴和后綴包圍的變量不會被Python解釋器修改: class PrefixPostfixTest: 但是,Python保留了有雙前導(dǎo)和雙末尾下劃線的名稱,用于特殊用途。 這樣的例子有,__init__對象構(gòu)造函數(shù),或__call__ --- 它使得一個對象可以被調(diào)用。 這些dunder方法通常被稱為神奇方法 - 但Python社區(qū)中的許多人(包括我自己)都不喜歡這種方法。 最好避免在自己的程序中使用以雙下劃線(“dunders”)開頭和結(jié)尾的名稱,以避免與將來Python語言的變化產(chǎn)生沖突。 5.單下劃線 _按照習(xí)慣,有時候單個獨立下劃線是用作一個名字,來表示某個變量是臨時的或無關(guān)緊要的。 例如,在下面的循環(huán)中,我們不需要訪問正在運行的索引,我們可以使用“_”來表示它只是一個臨時值: for _ in range(32): 你也可以在拆分(unpacking)表達式中將單個下劃線用作“不關(guān)心的”變量,以忽略特定的值。 同樣,這個含義只是“依照約定”,并不會在Python解釋器中觸發(fā)特殊的行為。 單個下劃線僅僅是一個有效的變量名稱,會有這個用途而已。 在下面的代碼示例中,我將汽車元組拆分為單獨的變量,但我只對顏色和里程值感興趣。 但是,為了使拆分表達式成功運行,我需要將包含在元組中的所有值分配給變量。 在這種情況下,“_”作為占位符變量可以派上用場: 'red', 'auto', 12, 3812.4) 除了用作臨時變量之外,“_”是大多數(shù)Python REPL中的一個特殊變量,它表示由解釋器評估的最近一個表達式的結(jié)果。 這樣就很方便了,比如你可以在一個解釋器會話中訪問先前計算的結(jié)果,或者,你是在動態(tài)構(gòu)建多個對象并與它們交互,無需事先給這些對象分配名字: >> 20 + 3 Python下劃線命名模式 - 小結(jié)以下是一個簡短的小結(jié),即“速查表”,羅列了我在本文中談到的五種Python下劃線模式的含義:
|
|
來自: LibraryPKU > 《Python》