您好,登錄后才能下訂單哦!
什么是 Python? Python 之父 Guido van Rossum 說:Python是一種高級程序語言,其核心設計哲學是代碼可讀性和語法,能夠讓程序員用很少的代碼來表達自己的想法。
對于我來說,學習 Python 的首要原因是,Python 是一種可以優雅編程的語言。它能夠簡單自然地寫出代碼和實現我的想法。
另一個原因是我們可以將 Python 用在很多地方:人工智能、數據科學、Web 開發和機器學習等都可以使用 Python 來開發。
國慶期間后臺有小伙伴留言問我:“Python變量和方法名稱中單下劃線和雙下劃線的含義是什么?”我想一些初學者或者經驗尚淺的朋友一定也會有這個疑問,所以今天我就來跟大家聊聊Python中這個很重要的“下劃線”!
單下劃線和雙下劃線在Python變量和方法名稱中都各有其含義。有一些含義僅僅是依照約定,被視作是對程序員的提示 - 而有一些含義是由Python解釋器嚴格執行的。
那么,下面就為大家介紹一下Python中單下劃線和雙下劃線("dunder")的各種含義和命名約定,名稱修飾(name mangling)的工作原理,以及它如何影響你自己的Python類。
下面將討論以下五種下劃線模式和命名約定,以及它們如何影響Python程序的行為:
單前導下劃線:_var
單末尾下劃線:var_
雙前導下劃線:__var
雙前導和末尾下劃線:__var__
單下劃線:_
1、單前導下劃線 _var
程序員使用名稱前的單下劃線,用于指定該名稱屬性為“私有”。這有點類似于慣例,為了使其他人(或你自己)使用這些代碼時將會知道以“_”開頭的名稱只供內部使用。正如Python文檔中所述:
以下劃線“_”為前綴的名稱(如_spam)應該被視為API中非公開的部分(不管是函數、方法還是數據成員)。此時,應該將它們看作是一種實現細節,在修改它們時無需對外部通知。
正如上面所說,這確實類似一種慣例,因為它對解釋器來說確實有一定的意義,如果你寫了代碼“from <模塊/包名> import *”,那么以“_”開頭的名稱都不會被導入,除非模塊或包中的“__all__”列表顯式地包含了它們。
看看下面的例子:
class Test:
def __init__(self):
self.foo = 11
self._bar = 23
如果你實例化此類,并嘗試訪問在__init__構造函數中定義的foo和_bar屬性,會發生什么情況? 讓我們來看看:
>>> t = Test()
>>> t.foo
11
>>> t._bar
23
你會看到_bar中的單個下劃線并沒有阻止我們“進入”類并訪問該變量的值。
這是因為Python中的單個下劃線前綴僅僅是一個約定 - 至少相對于變量和方法名而言。
但是,前導下劃線的確會影響從模塊中導入名稱的方式。
假設你在一個名為my_module的模塊中有以下代碼:
# This is my_module.py:
def external_func():
return 23
def _internal_func():
return 42
現在,如果使用通配符從模塊中導入所有名稱,則Python不會導入帶有前導下劃線的名稱(除非模塊定義了覆蓋此行為的__all__列表):
>>> from my_module import *
>>> external_func()
23
>>> _internal_func()
NameError: "name '_internal_func' is not defined"
順便說一下,應該避免通配符導入,因為它們使名稱空間中存在哪些名稱不清楚。 為了清楚起見,堅持常規導入更好。
與通配符導入不同,常規導入不受前導單個下劃線命名約定的影響:
>>> import my_module
>>> my_module.external_func()
23
>>> my_module._internal_func()
42
我們知道這一點可能有點令人困惑。 如果你遵循PEP 8推薦,避免通配符導入,那么你真正需要記住的只有這個:
單個下劃線是一個Python命名約定,表示這個名稱是供內部使用的。 它通常不由Python解釋器強制執行,僅僅作為一種對程序員的提示。
2、單末尾下劃線 var_
有時候,一個變量的最合適的名稱已經被一個關鍵字所占用。 因此,像class或def這樣的名稱不能用作Python中的變量名稱。 在這種情況下,你可以附加一個下劃線來解決命名沖突:
>>> def make_object(name, class):
SyntaxError: "invalid syntax"
>>> def make_object(name, class_):
... pass
總之,單個末尾下劃線(后綴)是一個約定,用來避免與Python關鍵字產生命名沖突。 PEP 8解釋了這個約定。
3、雙前導下劃線 __var
名稱(具體為一個方法名)前雙下劃線(__)的用法并不是一種慣例,對解釋器來說它有特定的意義。Python中的這種用法是為了避免與子類定義的名稱沖突。Python文檔指出,“__spam”這種形式(至少兩個前導下劃線,最多一個后續下劃線)的任何標識符將會被“_classname__spam”這種形式原文取代,在這里“classname”是去掉前導下劃線的當前類名。
例如下面的例子:
>>> class A(object):
... def _internal_use(self):
... pass
... def __method_name(self):
... pass
...
>>> dir(A())
['_A__method_name', ..., '_internal_use']
正如所預料的,“_internal_use”并未改變,而“__method_name”卻被變成了“_ClassName__method_name”。此時,如果你創建A的一個子類B,那么你將不能輕易地覆寫A中的方法“__method_name”。
>>> class B(A):
... def __method_name(self):
... pass
...
>>> dir(B())
['_A__method_name', '_B__method_name', ..., '_internal_use']
這里的功能幾乎和Java中的final方法和C++類中標準方法(非虛方法)一樣。
4、雙前導和雙末尾下劃線 _var_
也許令人驚訝的是,如果一個名字同時以雙下劃線開始和結束,則不會應用名稱修飾。 由雙下劃線前綴和后綴包圍的變量不會被Python解釋器修改:
class PrefixPostfixTest:
def __init__(self):
self.__bam__ = 42
>>> PrefixPostfixTest().__bam__
42
但是,Python保留了有雙前導和雙末尾下劃線的名稱,用于特殊用途。 這樣的例子有,__init__對象構造函數,或__call__ --- 它使得一個對象可以被調用。
這些dunder方法通常被稱為神奇方法 - 但Python社區中的許多人都不喜歡這種方法。
最好避免在自己的程序中使用以雙下劃線(“dunders”)開頭和結尾的名稱,以避免與將來Python語言的變化產生沖突。
5、單下劃線 _
通常情況下,會在以下3種場景中使用:
1、在解釋器中:在這種情況下,“_”代表交互式解釋器會話中上一條執行的語句的結果。這種用法首先被標準CPython解釋器采用,然后其他類型的解釋器也先后采用。
>>> _ Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name '_' is not defined
>>> 42
>>> _
42
>>> 'alright!' if _ else ':('
'alright!'
>>> _
'alright!'
2、作為一個名稱:這與上面一點稍微有些聯系,此時“_”作為臨時性的名稱使用。這樣,當其他人閱讀你的代碼時將會知道,你分配了一個特定的名稱,但是并不會在后面再次用到該名稱。例如,下面的例子中,你可能對循環計數中的實際值并不感興趣,此時就可以使用“_”。
n = 42
for _ in range(n):
do_something()
3、國際化:也許你也曾看到”_“會被作為一個函數來使用。這種情況下,它通常用于實現國際化和本地化字符串之間翻譯查找的函數名稱,這似乎源自并遵循相應的C約定。
例如,在Django文檔“轉換”章節中,你將能看到如下代碼:
from django.utils.translation import ugettext as _
from django.http import HttpResponse
def my_view(request):
output = _("Welcome to my site.")
return HttpResponse(output)
可以發現,場景二和場景三中的使用方法可能會相互沖突,所以我們需要避免在使用“_”作為國際化查找轉換功能的代碼塊中同時使用“_”作為臨時名稱。
總結:
Python下劃線命名模式 - 小結
以下是一個簡短的小結,即“速查表”,羅列了本文中談到的五種Python下劃線模式的含義:
歡迎加入 51軟件測試大家庭,在這里你將獲得【最新行業資訊】,【免費測試工具安裝包】,【軟件測試技術干貨】,【面試求職技巧】... 51與你共同學習,一起成長!期待你的加入: QQ 群: 755431660
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。