五種Python下劃線模式速查表：

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

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

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

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

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

單末尾下劃線 var_

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

>>> def make_object(name, class):SyntaxError: 'invalid syntax'>>> def make_object(name, class_):... pass

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

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

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

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

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

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

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

讓我們用內(nèi)置的dir()函數(shù)來(lái)看看這個(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ì)象屬性的列表。 讓我們來(lái)看看這個(gè)列表，并尋找我們的原始變量名稱(chēng)foo，_bar和__baz - 我保證你會(huì)注意到一些有趣的變化。

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

__baz出什么情況了？

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

讓我們創(chuàng)建另一個(gè)擴(kuò)展Test類(lèi)的類(lèi)，并嘗試重寫(xiě)構(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類(lèi)的實(shí)例上嗎？ 我們來(lái)看一看：

>>> t2 = ExtendedTest()>>> t2.foo’overridden’>>> t2._bar’overridden’>>> t2.__bazAttributeError: '’ExtendedTest’ object has no attribute ’__baz’'

等一下，當(dāng)我們嘗試查看t2 .__ baz的值時(shí)，為什么我們會(huì)得到AttributeError？ 名稱(chēng)修飾被再次觸發(fā)了！ 事實(shí)證明，這個(gè)對(duì)象甚至沒(méi)有__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’

但原來(lái)的_Test__baz還在：

>>> t2._Test__baz42

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

class ManglingTest: def __init__(self): self.__mangled = ’hello’ def get_mangled(self): return self.__mangled>>> ManglingTest().get_mangled()’hello’>>> ManglingTest().__mangledAttributeError: '’ManglingTest’ object has no attribute ’__mangled’'

名稱(chēng)修飾是否也適用于方法名稱(chēng)？ 是的，也適用。名稱(chēng)修飾會(huì)影響在一個(gè)類(lèi)的上下文中，以?xún)蓚€(gè)下劃線字符（'dunders'）開(kāi)頭的所有名稱(chēng)：

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)用名稱(chēng)修飾的例子：

_MangledGlobal__mangled = 23class MangledGlobal: def test(self): return __mangled>>> MangledGlobal().test()23

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

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

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

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

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

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

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

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

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

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

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

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

單下劃線 _

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

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

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

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

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

>>> car = (’red’, ’auto’, 12, 3812.4)>>> color, _, _, mileage = car>>> color’red’>>> mileage3812.4>>> _12

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

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

>>> 20 + 323>>> _23>>> print(_)23>>> list()[]>>> _.append(1)>>> _.append(2)>>> _.append(3)>>> _[1, 2, 3]

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持好吧啦網(wǎng)。