【ZZ】Python下劃線與命名規範

Python下劃線與命名規範

如下分四種狀況說明下劃線的做用，python對成員域沒有嚴格控制，大部份只是做爲命名規範存在，如下英文部份摘自python官方網站

_single_leading_underscore: weak "internal use" indicator.  E.g. "from M import *" does not import objects whose name starts with an underscore.

_單下劃線開頭：弱「內部使用」標識，如：」from M import *」，將不導入全部如下劃線開頭的對象，包括包、模塊、成員

single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, e.g.Tkinter.Toplevel(master, class_='ClassName')

單下劃線結尾_：只是爲了不與python關鍵字的命名衝突

__double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo; see below).

__雙下劃線開頭：模塊內的成員，表示私有成員，外部沒法直接調用

__double_leading_and_trailing_underscore__: "magic" objects or attributes that live in user-controlled namespaces.  E.g. __init__,__import__ or __file__.  Never invent such names; only use them as documented.

 

__雙下劃線開頭雙下劃線結尾__：指那些包含在用戶沒法控制的命名空間中的「魔術」對象或屬性，如類成員的__name__ 、__doc__、__init__、__import__、__file__、等。推薦永遠不要將這樣的命名方式應用於本身的變量或函數。

另外，以上說的大部分都是與模塊成員相關的，包和模塊的命名規範又有哪些須要注意的呢？

Package and Module Names                
Modules should have short, all-lowercase names.  Underscores can be used in the module name if it improves readability.  Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.     
Since module names are mapped to file names, and some file systems are case insensitive and truncate long names, it is important that module names be chosen to be fairly short -- this won't be a problem on Unix,but it may be a problem when the code is transported to older Mac or Windows versions, or DOS.

包和模塊：模塊應該使用盡量短的、全小寫命名，能夠在模塊命名時使用下劃線以加強可讀性。一樣包的命名也應該是這樣的，雖然其並不鼓勵下劃線。

以上這些主要是考慮模塊名是與文件夾相對應的，所以須要考慮文件系統的一些命名規則的，好比Unix系統對大小寫敏感，而過長的文件名會影響其在Windows\Mac\Dos等系統中的正常使用。

Class Names
Almost without exception, class names use the CapWords convention.Classes for internal use have a leading underscore in addition.

類：幾乎毫無例外的，類名都使用首字母大寫開頭(Pascal命名風格)的規範。使用_單下劃線開頭的類名爲內部使用，上面說的from M import *默認不被告導入的狀況。

Exception Names

Because exceptions should be classes, the class naming convention applies here.  However, you should use the suffix "Error" on your exception names (if the exception actually is an error).

 

異常：由於異常也是一個類，因此遵照類的命名規則。此外，若是異常實際上指代一個錯誤的話，應該使用「Error」作後綴

Global Variable Names

(Let's hope that these variables are meant for use inside one module only.)  The conventions are about the same as those for functions.Modules that are designed for use via "from M import *" should use the __all__ mechanism to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which you might want to do to indicate these globals are "module non-public").

 

Function Names
Function names should be lowercase, with words separated by underscores as necessary to improve readability. mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

函數：小寫、下劃線分詞，如def has_key(ch):

Function and method arguments

Always use 'self' for the first argument to instance methods.Always use 'cls' for the first argument to class methods.If a function argument's name clashes with a reserved keyword, it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption.  Thus "print_" is better than "prnt".  (Perhaps better is to avoid such clashes by using a synonym.)

 

Method Names and Instance Variables
Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability. Use one leading underscore only for non-public methods and instance variables.
To avoid name clashes with subclasses, use two leading underscores to invoke Python's name mangling rules.

Python mangles these names with the class name: if class Foo has an attribute named __a, it cannot be accessed by Foo.__a.  (An insistent
user could still gain access by calling Foo._Foo__a.)  Generally, double
leading underscores should be used only to avoid name conflicts with
attributes in classes designed to be subclassed.
Note: there is some controversy about the use of __names (see below).

 

Constants
Constants are usually defined on a module level and written in all capital letters with underscores separating words.  Examples include MAX_OVERFLOW and TOTAL.

 

構造函數及其餘：

class a:

     def __init__(self):

              self._hour = 0

              self._minute = 0

      __init__爲類的構造函數，每次建立類對象時，都會執行構造函數。構造函數（__init__）會初始化類對象屬性，而且返回None。python類還能夠定義其餘的特殊方法，這些方法以前、以後都會有雙下劃線（__）。

       構造函數用單一的前置下劃線（_）來建立屬性。屬性名以單下劃線開頭。雖然在python語法中沒有特殊的含義，但單下劃線是python程序員使用類是約定的使用的符號，代表程序員不但願類的用戶直接訪問屬性。若是程序要求訪問屬性，程序員會提供其餘途徑。

私有屬性：

         python中，對象的屬性是確定能被訪問的——沒有辦法阻止其餘代碼訪問屬性。但python也提供了特殊的機制來防止任意的訪問數據。

        這種特殊機制叫作「名稱重整」，使用方法則爲：爲屬性名附加雙下劃線前綴（__）。來個例子？：

在類A的構造函數（__init__）中這樣寫到：

class A:

       def __init__(self):

             self.__hour = 0

B=A( )

         如今，若是你想採起經常使用的方法「print B.__hour」，那麼你將獲得的反饋信息不是理想的「0」，而是一則異常。咱們換個方式來試試：「print B._A__hour」

         如你所願了嗎？

         當構造函數的屬性名附加雙下劃線前綴（__）後，python就會建立「_類名__屬性名」這樣的屬性，而不是名爲「__屬性名」的屬性。

         值得說明的是，通過「名稱重整」後的屬性依然是能夠經過「對象._類名__屬性名」的方法訪問、甚至修改（如執行「B._A__hour = 5」是能夠經過的），但這樣的使用方式將違背做者的數據封裝意圖。

 

Python 用下劃線做爲變量前綴和後綴指定特殊變量。

_xxx      不能用'from module import *'導入 
__xxx__ 系統定義名字 
__xxx    類中的私有變量名 

核心風格：避免用下劃線做爲變量名的開始。

由於下劃線對解釋器有特殊的意義，並且是內建標識符所使用的符號，咱們建議程序員避免用下劃線做爲變量名的開始。通常來說，變量名_xxx被看做是「私有 的」，在模塊或類外不可使用。當變量是私有的時候，用_xxx 來表示變量是很好的習慣。由於變量名__xxx__對Python 來講有特殊含義，對於普通的變量應當避免這種命名風格。

"單下劃線" 開始的成員變量叫作保護變量，意思是隻有類對象和子類對象本身能訪問到這些變量；
"雙下劃線" 開始的是私有成員，意思是隻有類對象本身能訪問，連子類對象也不能訪問到這個數據。

以單下劃線開頭（_foo）的表明不能直接訪問的類屬性，需經過類提供的接口進行訪問，不能用「from xxx import *」而導入；以雙下劃線開頭的（__foo）表明類的私有成員；以雙下劃線開頭和結尾的（__foo__）表明python裏特殊方法專用的標識，如 __init__（）表明類的構造函數。

 

結論：

1、_xxx     不能用於’from module import *’ 以單下劃線開頭的表示的是protected類型的變量。即保護類型只能容許其自己與子類進行訪問。

2、__xxx    雙下劃線的表示的是私有類型的變量。只能是容許這個類自己進行訪問了。連子類也不能夠

3、__xxx___定義的是特列方法。像__init__之類的