Python下劃線命名模式
五種Python下劃線模式速查表:

單前導(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)志,說(shuō):
“嘿,這不是真的要成為類的公共接口的一部分。不去管它就好。“
單末尾下劃線 var_
有時(shí)候,一個(gè)變量的最合適的名稱已經(jīng)被一個(gè)關(guān)鍵字所占用。 因此,像class或def這樣的名稱不能用作Python中的變量名稱。 在這種情況下,你可以附加一個(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ì)于以雙下劃線開頭的Python類的屬性(包括變量和方法),情況就有點(diǎn)不同了。
雙下劃線前綴會(huì)導(dǎo)致Python解釋器重寫屬性名稱,以避免子類中的命名沖突。
這也叫做名稱修飾(name mangling) - 解釋器更改變量的名稱,以便在類被擴(kuò)展的時(shí)候不容易產(chǎn)生沖突。
我知道這聽起來(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è)列表,并尋找我們的原始變量名稱foo,_bar和__baz - 我保證你會(huì)注意到一些有趣的變化。
- self.foo變量在屬性列表中顯示為未修改為foo。
- self._bar的行為方式相同 - 它以_bar的形式顯示在類上。 就像我之前說(shuō)過(guò)的,在這種情況下,前導(dǎo)下劃線僅僅是一個(gè)約定。 給程序員一個(gè)提示而已。
- 然而,對(duì)于self.__baz而言,情況看起來(lái)有點(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í)例上嗎? 我們來(lái)看一看:
>>> 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'
但原來(lái)的_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來(lái)引用_MangledGlobal__mangled全局變量。
Python解釋器自動(dòng)將名稱__mangled擴(kuò)展為_MangledGlobal__mangled,因?yàn)樗詢蓚€(gè)下劃線字符開頭。這表明名稱修飾不是專門與類屬性關(guān)聯(lián)的。它適用于在類上下文中使用的兩個(gè)下劃線字符開頭的任何名稱。
有很多要吸收的內(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),以便你能夠理解名稱修飾的總體思路,以及我向您展示的一些其他的行為。如果有一天你和它們不期而遇,你會(huì)知道在文檔中按什么來(lái)查。
雙前導(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é)尾的名稱,以避免與將來(lái)Python語(yǔ)言的變化產(chǎn)生沖突。
單下劃線 _
按照習(xí)慣,有時(shí)候單個(gè)獨(dú)立下劃線是用作一個(gè)名字,來(lái)表示某個(gè)變量是臨時(shí)的或無(wú)關(guān)緊要的。
例如,在下面的循環(huá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è)有效的變量名稱,會(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ì)象并與它們交互,無(wú)需事先給這些對(duì)象分配名字:
>>> 20 + 3 23 >>> _ 23 >>> print(_) 23 >>> list() [] >>> _.append(1) >>> _.append(2) >>> _.append(3) >>> _ [1, 2, 3]
到此這篇關(guān)于Python下劃線命名模式的文章就介紹到這了,更多相關(guān)Python下劃線命名模式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Python上下文管理器的用法(Context Manager)
上下文管理器是Python中管理資源分配與釋放的重要機(jī)制,通過(guò)with語(yǔ)句實(shí)現(xiàn)資源的自動(dòng)管理,它適用于文件操作、數(shù)據(jù)庫(kù)連接、線程鎖管理等場(chǎng)景,可保證資源正確釋放,本文總結(jié)了上下文管理器的實(shí)現(xiàn)方式、應(yīng)用場(chǎng)景、最佳實(shí)踐和高級(jí)用法,旨在幫助開發(fā)者更好地掌握這一強(qiáng)大工具2026-04-04
詳解Pandas的三大利器(map,apply,applymap)
這篇文章主要為大家介紹了pandas中的三大利器: map、apply、applymap,他們經(jīng)常在進(jìn)行數(shù)據(jù)處理的時(shí)候用到,需要的可以參考一下2022-02-02
win10下tensorflow和matplotlib安裝教程
這篇文章主要為大家詳細(xì)介紹了win10下tensorflow和matplotlib安裝教程,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-09-09
使用Python實(shí)現(xiàn)with結(jié)構(gòu)的@contextmanager方法詳解
這篇文章主要介紹了使用Python實(shí)現(xiàn)with結(jié)構(gòu)的@contextmanager方法詳解,這個(gè)結(jié)構(gòu)的好處,一個(gè)是簡(jiǎn)潔,一個(gè)是當(dāng)我們對(duì)文件操作的邏輯很長(zhǎng)的時(shí)候,不會(huì)因?yàn)橥岁P(guān)閉文件而造成不必要的錯(cuò)誤,需要的朋友可以參考下2023-07-07
Python中報(bào)錯(cuò) “TypeError: ‘list‘ object is&n
這篇文章主要介紹了Python中報(bào)錯(cuò) “TypeError: ‘list‘ object is not callable”問題及解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-09-09
Python cookbook(字符串與文本)針對(duì)任意多的分隔符拆分字符串操作示例
這篇文章主要介紹了Python cookbook(字符串與文本)針對(duì)任意多的分隔符拆分字符串操作,結(jié)合實(shí)例形式分析了Python使用split()及正則表達(dá)式進(jìn)行字符串拆分操作相關(guān)實(shí)現(xiàn)技巧,需要的朋友可以參考下2018-04-04

