pep-8要求概括

代碼佈局
縮進
每一個縮進級別使用4個空格。

連續行應使用Python的隱式行鏈接括號，括號和大括號，或使用懸掛縮進 來垂直對齊包裝元素。當使用懸掛式縮進時，應考慮如下內容：第一行應該沒有任何爭論，應該使用進一步的縮進來將本身明確地區分爲延續線。

是：

＃與開頭分隔符對齊。
foo = long_function_name（var_one，var_two，
var_three，var_four）

＃包含更多縮進區別於其餘縮進。
def long_function_name（
var_one，var_two，var_three，
var_four）：
打印（var_one）

＃懸掛縮進應該添加一個級別。
foo = long_function_name（
var_one，var_two，
var_three，var_four）
沒有：

＃不使用垂直對齊時禁止第一行的參數。
foo = long_function_name（var_one，var_two，
var_three，var_four）

＃縮進所需的進一步縮進沒法區分。
def long_function_name（
var_one，var_two，var_three，
var_four）：
打印（var_one）
四維空間規則對於延續線是可選的。

可選的：

＃懸掛縮進*能夠縮進至4個之內。
foo = long_function_name（
var_one，var_two，
var_three，var_four）
當if語句的條件部分足夠長以致於須要將其寫入多行時，值得注意的是，兩個字符關鍵字（即if）的組合，再加上一個空格以及一個左括號會建立一個天然的多行有條件的後續行使用4空格縮進。這可能會與嵌套在if語句中的縮進代碼套件產生視覺衝突，該套件天然會縮進到4個空格。這個PEP沒有明確地說明如何（或是否）在if語句中進一步從視覺上區分這些條件行與嵌套套件。這種狀況下的可接受選項包括但不限於：

＃沒有額外的縮進。
若是（this_is_one_thing和
that_is_another_thing）：
作一點事（）

 

多行結構中的右括號/括號/括號能夠排列在列表的最後一行的第一個非空白字符下，以下所示：

my_list = [
1，2，3，
4，5，6，
]
result = some_function_that_takes_arguments（
'a'，'b'，'c'，
'd'，'e'，'f'，
）
或者可能會在啓動多行構建的行的第一個字符下排列，以下所示：

my_list = [
1，2，3，
4，5，6，
]
result = some_function_that_takes_arguments（
'a'，'b'，'c'，
'd'，'e'，'f'，
）
標籤或空格？
空格是首選的縮進方法。

選項卡應徹底用於與已用選項卡縮進的代碼保持一致。

Python 3不容許混合使用製表符和空格來縮進。

Python 2代碼縮進的製表符和空格混合應該轉換爲僅使用空格。

當使用-t選項調用Python 2命令行解釋器時，它會發出有關非法混合選項卡和空格的代碼的警告。使用-tt時，這些警告會變成錯誤。這些選項是強烈建議！

最大線路長度
將全部行限制爲最多79個字符。

對於具備較少結構限制（文檔字符串或註釋）的長文本塊，流水線長度應限制爲72個字符。

限制所需的編輯器窗口寬度可使多個文件並排打開，而且在使用在相鄰列中顯示兩個版本的代碼審閱工具時能夠很好地工做。

大多數工具的默認包裝破壞了代碼的可視化結構，使其更難以理解。選擇限制是爲了不在窗口寬度設置爲80的編輯器中進行包裝，即便該工具在包裝線條時在最終列中放置了標記符號。一些基於Web的工具可能根本不提供動態換行。

有些團隊強烈但願更長的線條長度。對於專門或主要由能夠就此問題達成一致的團隊維護的代碼，能夠將標稱行長度從80個字符增長到100個字符（有效地將最大長度增長到99個字符），條件是仍然包含註釋和文檔字符串72個字符。

Python標準庫是保守的，須要將行限制爲79個字符（而且文檔字符串/註釋爲72）。

包裝長行的首選方式是在括號，括號和大括號內使用Python的隱含行連續。經過在圓括號中包裝表達式，能夠將多條線分紅多行。這些應該優先使用反斜槓進行續行。

有時反斜槓可能仍然適用。例如，long，multiple with -statements不能使用隱式延續，因此反斜槓是能夠接受的：

打開（'/ path / to / some / file / you / want / to / read'）做爲file_1，\
打開（'/ path / to / some / file / being / written'，'w'）做爲file_2：
file_2.write（file_1.read（））
（參見前面的討論多if語句對此類多的缺口的進一步思考與 -statements。）

另外一個這樣的狀況是assert語句。

確保適當縮進續行。

應該在二元運算符以前仍是以後斷行？
幾十年來，推薦的風格是在二元運營商以後打破。可是這會以兩種方式傷害可讀性：操做員傾向於分散在屏幕上的不一樣列上，而且每一個操做員都從操做數移動到前一行。在這裏，眼睛必須作額外的工做來判斷哪些項目被添加以及哪些被減去：

＃否：操做員遠離他們的操做數
收入=（gross_wages +
taxable_interest +
（股息 - qualified_dividends） -
ira_deduction -
student_loan_interest）
爲了解決這個可讀性問題，數學家和他們的出版商遵循相反的慣例。Donald Knuth在他的「 計算機與排版」系列中解釋了傳統規則：「儘管二進制操做和關係以後段落中的公式老是中斷，但顯示的公式老是在二進制操做以前中斷」。

遵循數學的傳統一般會產生更具可讀性的代碼：

＃是：容易使操做符與操做數匹配
收入=（gross_wages
+ taxable_interest
+（股息 - qualified_dividends）
- ira_deduction
- student_loan_interest）
在Python代碼中，只要約定在本地一致，就能夠在二元運算符以前或以後中斷。建議使用新代碼Knuth的風格。

空白行
用兩個空白行圍繞頂層函數和類定義。

一個類中的方法定義被一個空行包圍。

可使用額外的空白行（節省空間）來分隔相關功能組。在一堆相關的單行程序（例如一組虛擬執行程序）之間可能會省略空白行。

在函數中使用空行來節省邏輯部分。

Python接受控件-L（即^ L）換頁字符做爲空格; 許多工具將這些字符視爲頁面分隔符，所以您可使用它們來分隔文件相關部分的頁面。請注意，有些編輯器和基於Web的代碼查看器可能沒法將控件-L識別爲換頁，而且會在其位置顯示另外一個字形。

源文件編碼
核心Python發行版中的代碼應始終使用UTF-8（或Python 2中的ASCII）。

使用ASCII（在Python 2中）或UTF-8（在Python 3中）的文件不該該有編碼聲明。

在標準庫中，非默認編碼應僅用於測試目的，或者當評論或文檔字符串須要說起包含非ASCII字符的做者姓名; 不然，使用\ x， \ u，\ U或\ N轉義符是將非ASCII數據包含在字符串文本中的首選方法。

對於Python 3.0及更高版本，爲標準庫規定了如下策略（請參閱PEP 3131）：Python標準庫中的全部標識符必須使用純ASCII標識符，而且應儘量使用英文單詞（在許多狀況下，縮寫和技術使用的術語不是英語）。另外，字符串文字和註釋也必須使用ASCII。惟一的例外是（a）測試非ASCII功能的測試用例，以及（b）做者的名稱。名稱不是基於拉丁字母（拉丁語-1，ISO / IEC 8859-1字符集）的做者必須提供這個字符集中他們的名字的音譯。

鼓勵全球受衆開放源碼項目採起相似的政策。

進口
進口一般應該分開，例如：

是的：進口操做系統
進口系統

No：import sys，os
能夠這樣說：

從子流程導入Popen，PIPE
導入始終放在文件的頂部，緊跟在任何模塊註釋和文檔字符串以後，以及模塊全局變量和常量以前。

進口應按如下順序進行分組：

標準庫導入
相關的第三方進口
本地應用程序/庫特定的導入
您應該在每組導入之間留出空行。

建議使用絕對導入，由於若是導入系統配置不正確（例如，當某個包中的目錄在sys.path中結束時），它們一般更具可讀性而且每每表現得更好（或者至少提供更好的錯誤消息）：

導入mypkg.sibling
從mypkg導入同級
來自mypkg.sibling導入示例
然而，明確的相對進口是絕對進口的可接受的替代方案，特別是在處理複雜的包裝佈局時，使用絕對進口的狀況會沒必要要地冗長：

從。導入兄弟姐妹
來自.sibling導入示例
標準庫代碼應避免複雜的包佈局，並始終使用絕對導入。

隱進口相對應永遠不會被使用，並在Python 3已被刪除。

從包含類的模塊中導入一個類時，一般能夠這樣描述：

從myclass導入MyClass
從foo.bar.yourclass導入YourClass
若是此拼寫致使本地名稱衝突，則拼寫它們

導入myclass
導入foo.bar.yourclass
並使用「myclass.MyClass」和「foo.bar.yourclass.YourClass」。

應避免使用通配符導入（來自<module> import *），由於它們不清楚命名空間中存在哪些名稱，使讀者和許多自動化工具混淆。對於通配符導入有一個有效的用例，即從新發布內部接口做爲公共API的一部分（例如，用可選加速器模塊的定義覆蓋接口的純Python實現，並確切定義哪些定義預先覆蓋不知道）。

以這種方式從新發布名稱時，如下有關公共和內部接口的準則仍適用。

模塊級別的dunder名稱
模塊級「dunders」（即名稱具備兩個前緣和兩個縱下劃線）如__all__，__author__，__version__等應被放置在模塊文檔字符串以後，但在任何導入語句之外 從__future__進口。Python要求將來 - 導入必須出如今除docstrings之外的任何其餘代碼以前的模塊中。

例如：

「」「這是示例模塊。

這個模塊作的東西。
「」」

從__future__導入barry_as_FLUFL

__all__ = ['a'，'b'，'c']
__version__ ='0.1'
__author__ ='Cardinal Biggles'

字符串行情
　　在Python中，單引號字符串和雙引號字符串是相同的。這個PEP不會爲此提出建議。選擇一個規則並堅持下去。可是，若是字符串包含單引號或雙引號字符，請使用另外一個避免字符串中的反斜槓。它提升了可讀性。

對於三引號字符串，老是使用雙引號字符與PEP 257中的docstring約定一致。

表達式和語句中的空格
寵物Peeves
在如下狀況下避免無關的空白：

當即在括號，括號或大括號內。

是：垃圾郵件（火腿[1]，{雞蛋：2}）
否：垃圾郵件（火腿[1]，{雞蛋：2}）
尾隨逗號和後面的右括號之間。

是：foo =（0，）
否：bar =（0，）
在逗號，分號或冒號前面：

是：若是x == 4：print x，y; x，y = y，x
否：若是x == 4：print x，y; x，y = y，x
然而，在一個切片中，冒號的做用就像一個二元運算符，而且兩邊應該有相同的數量（將其視爲最低優先級的運算符）。在擴展切片中，兩個冒號必須具備相同量的間距。例外：當省略切片參數時，空格被省略。

是：

火腿[1：9]，火腿[1：9：3]，火腿[：9：3]，火腿[1：3]，火腿[1：9：]
火腿[下：上]，火腿[下：上：]，火腿[下::步]
火腿[低+偏移：高+偏移]
火腿[：upper_fn（x）：step_fn（x）]，火腿[:: step_fn（x）]
火腿[低+偏移：高+偏移]
沒有：

火腿[低+偏移：高+偏移]
火腿[1：9]，火腿[1：9]，火腿[1：9：3]
火腿[下：：上]
火腿[：上]
緊接在開始函數調用參數列表的開括號以前：

是：垃圾郵件（1）
否：垃圾郵件（1）
緊接在開始索引或切片的開括號以前：

是：dct ['key'] = lst [index]
否：dct ['key'] = lst [index]
在一個賦值（或其餘）運算符周圍的多個空間將其與另外一個對齊。

是：

x = 1
y = 2
long_variable = 3
沒有：

x = 1
y = 2
long_variable = 3
其餘建議
避免在任何地方拖曳空白。由於它一般是不可見的，因此可能會引發混淆：例如，反斜槓後跟一個空格，換行符不會被視爲行延續標記。有些編輯不保留它，許多項目（如CPython自己）都預先提交了拒絕它的鉤子。

始終圍繞這些二元運算符在任一側使用一個空格：賦值（=），擴充賦值（+ =，- = 等），比較（==，<，>，！=，<>，<=， > =，在，不在，是，是否是），布爾值（和， 或，不）。

若是使用具備不一樣優先級的運營商，請考慮在優先級最低的運營商周圍添加空白。用你本身的判斷力; 可是，從不使用多於一個空格，而且在二元運算符的兩側始終具備相同數量的空白。

是：

我=我+ 1
提交+ = 1
x = x * 2 - 1
hypot2 = x * x + y * y
c =（a + b）*（ab）
沒有：

I = I + 1
提交+ = 1
x = x * 2 - 1
hypot2 = x * x + y * y
c =（a + b）*（a-b）
用於指示關鍵字參數或默認參數值時，不要在=符號周圍使用空格。

是：

def complex（real，imag = 0.0）：
迴歸魔術（r =真實，i =形象）
沒有：

def complex（real，imag = 0.0）：
迴歸魔術（r =真實，i =形象）
功能註釋應該使用冒號的正常規則，而且若是存在的話，在- >箭頭周圍老是有空格。（有關功能註釋的更多信息，請參見 下面的函數註釋。）

是：

def munge（輸入：AnyStr）：...
def munge（） - > AnyStr：...
沒有：

def munge（輸入：AnyStr）：...
def munge（） - > PosInt：...
將參數註釋與默認值組合時，請在=符號周圍使用空格（但僅適用於那些同時具備註釋和默認值的參數）。

是：

def munge（sep：AnyStr = None）：...
def munge（輸入：AnyStr，sep：AnyStr = None，限制= 1000）：...
沒有：

def munge（輸入：AnyStr =無）：...
def munge（輸入：AnyStr，限制= 1000）：...
一般不鼓勵複合語句（同一行上的多個語句）。

是：

若是foo =='blah'：
do_blah_thing（）
do_one（）
do_two（）
do_three（）
而不是：

if foo =='blah'：do_blah_thing（）
do_one（）; do_two（）; do_three（）
雖然有時能夠在同一行上放置一個if / for / while和一個小型主體，但從不爲多語句語句執行此操做。還要避免摺疊這麼長的線條！

而不是：

if foo =='blah'：do_blah_thing（）
for x in lst：total + = x
而t <10時：t =延遲（）
固然不：

if foo =='blah'：do_blah_thing（）
else：do_non_blah_thing（）

試試：something（）
最後：清理（）

do_one（）; do_two（）; do_three（long，argument，
列表，就像這樣）

若是foo =='blah'：one（）; 二（）; 三（）
什麼時候使用尾隨逗號
尾隨逗號一般是可選的，除了在製做一個元素的元組時是必須的（在Python 2中它們具備打印語句的語義）。爲了清楚起見，建議用（技術上冗餘的）括號括住後者。

是：

FILES =（'setup.cfg'，）
好，但使人困惑：

FILES ='setup.cfg'，
當尾隨逗號是多餘的時候，當使用版本控制系統時，當值，參數或導入的項目列表預計會隨時間擴展時，它們一般會頗有幫助。模式是將每一個值（等）單獨放在一行上，始終添加尾隨逗號，並在下一行添加右括號/括號/大括號。然而，在結束分隔符的同一行上有一個尾隨逗號是沒有意義的（除了上述單例元組的狀況外）。

是：

FILES = [
'setup.cfg'，
'tox.ini'，
]
初始化（文件，
錯誤=真，
）
沒有：

FILES = ['setup.cfg'，'tox.ini'，]
初始化（FILES，錯誤= True，）
註釋
與代碼相抵觸的評論比沒有評論更糟。在代碼更改時，始終優先保持評論的最新狀態！

評論應該是完整的句子。第一個單詞應該大寫，除非它是一個以小寫字母開頭的標識符（不要改變標識符的大小寫！）。

塊註釋一般由完整句子構成的一個或多個段落組成，每一個句子以一段時間結束。

除了最後一句以外，您應該在多句話評論的句末結束後使用兩個空格。

在寫英文時，請遵循Strunk和White。

非英語國家的Python編碼人員：請用英文寫下您的意見，除非您確信代碼不會被不會說您的語言的人閱讀。

阻止評論
塊註釋一般適用於跟隨它們的一些（或所有）代碼，並縮進到與該代碼相同的級別。塊註釋的每一行都以＃和單個空格開頭（除非它在註釋內縮進文本）。

塊註釋中的段落由包含單個＃的行分隔。

內聯註釋
謹慎使用內嵌評論。

內聯評論是對語句同一行的評論。內聯註釋應該與語句中的至少兩個空格分隔。他們應該以＃和單個空間開始。

內聯評論是沒必要要的，事實上，若是他們陳述明顯的話，就會分心。不要這樣作：

x = x + 1＃增量x
但有時候，這頗有用：

x = x + 1＃補償邊界
文檔字符串
編寫良好文檔字符串（又稱「文檔字符串」）的慣例在PEP 257中不朽。

爲全部公共模塊，函數，類和方法編寫文檔。Docstrings對於非公開方法不是必需的，但您應該有一個評論來描述該方法的功能。這條評論應該出如今def行以後。

PEP 257描述了良好的文檔字符串約定。請注意，最重要的是，結束多行文檔字符串的「」「應該單獨在一行上，例如：

「」「回到foobang

可選的plotz說先激烈地推銷bizbaz。
「」」
對於一個班輪文件，請將結尾「」「保留在同一行。

命名約定
Python庫的命名約定有點亂，因此咱們永遠不會獲得徹底一致的結果 - 不過，這裏是目前推薦的命名標準。應該爲這些標準編寫新的模塊和包（包括第三方框架），可是現有庫具備不一樣風格時，內部一致性是首選。

首要原則
做爲API的公共部分對用戶可見的名稱應遵循反映使用狀況而非實現狀況的約定。

描述性：命名樣式
有不少不一樣的命名風格。它有助於識別使用的命名風格，而無論它們的用途。

如下命名風格一般是可區分的：

b（單個小寫字母）

B（單個大寫字母）

小寫

lower_case_with_underscores

大寫

UPPER_CASE_WITH_UNDERSCORES

CapitalizedWords（或CapWords，或者駝峯-如此，由於它信件的顛簸外觀而得名[4] ）。這有時也被稱爲StudlyCaps。

注意：在CapWords中使用首字母縮略詞時，請首字母縮寫首字母縮寫詞的全部字母。所以HTTPServerError比HttpServerError好。

mixedCase（與大寫字母不一樣，由小寫字母開始！）

Capitalized_Words_With_Underscores（醜陋！）

還有使用簡短的惟一前綴將相關名稱組合在一塊兒的風格。這在Python中用處不大，但爲了完整性而提到。例如，os.stat（）函數返回一個元組，其元素傳統上具備諸如st_mode， st_size，st_mtime等名稱。（這樣作是爲了強調與POSIX系統調用結構體的字段的對應關係，這有助於程序員熟悉這一點。）

X11庫爲其全部公共功能使用了領先的X. 在Python中，這種風格一般被認爲是沒必要要的，由於屬性和方法名稱以一個對象爲前綴，而函數名稱以模塊名稱爲前綴。

此外，使用前導或尾隨下劃線的如下特殊表格被承認（這些一般能夠與任何案例慣例結合使用）：

_single_leading_underscore：弱的「內部使用」指標。例如，從M導入*不會導入名稱如下劃線開頭的對象。

single_trailing_underscore_：按慣例使用以免與Python關鍵字衝突，例如

Tkinter.Toplevel（master，class _ ='ClassName'）
__double_leading_underscore：當命名一個類屬性時，調用名字修改（在類FooBar中，__boo變成 _FooBar__boo ;見下文）。

__double_leading_and_trailing_underscore__：生活在用戶控制的命名空間中的「魔術」對象或屬性。例如__init__，__ import__或__file__。不要發明這樣的名字; 只有按照記錄使用它們。

規定性：命名約定
要避免的名稱
切勿使用字符'l'（小寫字母el），'O'（大寫字母oh）或'I'（大寫字母）做爲單個字符變量名稱。

在某些字體中，這些字符與數字1和0沒有區別。當試圖使用'l'時，請使用'L'。

ASCII兼容性
如描述的標準庫使用的標識符必須是ASCII兼容政策的PEP 3131。

包和模塊名稱
模塊應該有簡短的全小寫名稱。若是提升可讀性，則能夠在模塊名稱中使用下劃線。儘管不建議使用下劃線，Python包也應該有簡短的全小寫名稱。

當用C或C ++編寫的擴展模塊具備提供更高級別（例如更多面向對象）接口的伴隨Python模塊時，C / C ++模塊具備前導下劃線（例如_socket）。

類名稱
類名一般應該使用CapWords約定。

函數的命名約定可用於接口被記錄並主要用做可調用函數的狀況。

請注意，內置名稱有一個單獨的約定：大多數內置名稱是單個單詞（或兩個單詞一塊兒運行），CapWords約定僅用於異常名稱和內置常量。

輸入變量名稱
在PEP 484中引入的類型變量的名稱一般應該使用首選短名稱的CapWords：T，AnyStr，Num。建議將後綴_co或_contra添加到用於相應地聲明協變或逆變行爲的變量中。例子：

從鍵入import TypeVar

VT_co = TypeVar（'VT_co'，covariant = True）
KT_contra = TypeVar（'KT_contra'，contravariant = True）
例外名稱
由於異常應該是類，因此類命名約定在這裏適用。可是，您應該在異常名稱上使用後綴「錯誤」（若是異常其實是錯誤）。

全局變量名稱
（咱們但願這些變量只能在一個模塊中使用）。約定與函數約定相同。

設計用於經過M import *使用的模塊應該使用__all__機制來防止導出全局變量，或者使用用下劃線爲全局變量加前綴的舊約定（您可能想要指定這些全局變量是「模塊非公開的「）。

函數和變量名稱
函數名稱應該是小寫字母，必要時用下劃線分隔單詞以提升可讀性。

變量名稱與函數名稱遵循相同的約定。

mixedCase只容許在已是流行風格的上下文中使用（例如threading.py），以保持向後兼容性。

函數和方法參數
老是使用self做爲實例方法的第一個參數。

老是使用cls做爲類方法的第一個參數。

若是函數參數的名稱與保留關鍵字衝突，一般最好追加一個尾部下劃線而不是使用縮寫或拼寫損壞。所以，class_比clss好。（也許更好的是經過使用同義詞來避免這種衝突。）

方法名稱和實例變量
使用函數命名規則：必要時用小寫字母分隔下劃線，以提升可讀性。

僅對非公開方法和實例變量使用一個前導下劃線。

爲避免名稱與子類發生衝突，請使用兩個前導下劃線來調用Python的名稱修改規則。

Python將這些名稱與類名稱相沖突：若是類Foo具備名爲__a的屬性，則Foo .__ a將沒法訪問該屬性。（一個持久的用戶仍然能夠經過調用Foo._Foo__a來得到訪問權。）一般，雙引號下劃線應該僅用於避免名稱與設計爲子類的類中的屬性衝突。

注意：有關使用__names的爭議（見下文）。

常量
常量一般在模塊級定義，並用大寫字母和下劃線分隔單詞。例子包括 MAX_OVERFLOW和TOTAL。

設計繼承
老是要決定一個類的方法和實例變量（統稱爲「屬性」）是公開的仍是非公開的。若有疑問，請選擇非公開; 將公開屬性設置爲非公開更容易。

公共屬性是指您希​​望班級中不相關的客戶使用的屬性，以及您承諾避免向後不兼容的更改的屬性。非公開屬性是那些不打算供第三方使用的屬性; 您不保證非公開屬性不會更改，甚至不會被刪除。

這裏咱們不使用術語「private」，由於在Python中沒有任何屬性是真正的私有的（沒有一般沒必要要的工做量）。

另外一類屬性是屬於「子類API」（一般在其餘語言中稱爲「受保護」）的屬性。有些類被設計爲從類繼承，擴展或修改類的行爲方面。在設計這樣的類時，注意明確地決定哪些屬性是公開的，哪些屬性是子類API的一部分，哪些只能由基類使用。

考慮到這一點，這裏是Pythonic的指導方針：

公共屬性應該沒有前導下劃線。

若是您的公共屬性名稱與保留關鍵字衝突，請在屬性名稱後附加一個尾部下劃線。這比縮寫或拼寫錯誤更可取。（可是，儘管有這條規則，'cls'是任何已知爲類的變量或參數的首選拼寫，尤爲是類方法的第一個參數。）

注1：請參閱上面有關類方法的參數名稱建議。

對於簡單的公共數據屬性，最好僅公開屬性名稱，而不須要複雜的訪問器/增量器方法。請記住，若是您發現簡單的數據屬性須要增長功能行爲，則Python爲未來的加強提供了一條便捷途徑。在這種狀況下，使用屬性隱藏簡單數據屬性訪問語法後面的功能實現。

注1：屬性僅適用於新式類。

注2：嘗試保持功能行爲的反作用免費，儘管緩存等反作用一般很好。

注3：避免使用屬性進行計算量大的操做; 該屬性符號使得調用者相信訪問是（相對）便宜的。

若是你的類想要被子類化，而且你有不但願子類使用的屬性，考慮用雙前導下劃線命名它們，而且不要使用尾隨下劃線。這將調用Python的名稱修改算法，其中該類的名稱被修改成屬性名稱。這有助於避免屬性名稱衝突，若是子類無心中包含具備相同名稱的屬性。

注1：請注意，只有簡單的類名稱用於重名的名稱，因此若是子類選擇相同的類名稱和屬性名稱，仍然能夠得到名稱衝突。

注2：名稱修改可使某些用途，如調試和 __getattr __（），不太方便。然而，名稱修改算法有很好的文檔記錄，而且易於手動執行。

注3：不是每一個人都喜歡名字混搭。嘗試平衡避免意外名稱衝突與高級呼叫者潛在使用的需求。

公共和內部接口
任何向後兼容性保證僅適用於公共接口。所以，用戶必須可以清楚地區分公共和內部接口。

文檔化的接口被認爲是公開的，除非文檔明確聲明它們是臨時的或內部接口免於一般的向後兼容性保證。全部未公開的接口應該被假定爲內部的。

爲了更好地支持自省，模塊應該使用__all__屬性在其公共API中顯式聲明名稱。將__all__設置 爲空列表表示該模塊沒有公共API。

即便正確設置__all__，內部接口（包，模塊，類，函數，屬性或其餘名稱）仍應之前導下劃線做爲前綴。

若是任何包含名稱空間（包，模塊或類）被認爲是內部的，則接口也被認爲是內部接口。

應始終將導入的名稱視爲實現細節。其餘模塊不能依賴間接訪問這些導入的名稱，除非它們是包含模塊的API的明確記錄部分，例如os.path或從子模塊公開功能的包的__init__模塊。

編程建議
代碼的編寫方式不會影響Python的其餘實現（PyPy，Jython，IronPython，Cython，Psyco等）。

例如，不要依賴CPython有效地實現以a + = b 或a = a + b形式的語句的就地字符串鏈接。即便在CPython中，這種優化也很脆弱（它只適用於某些類型），而且在不使用refcounting的實現中徹底不存在。在庫的性能敏感部分，應該使用''.join（）表單來代替。這將確保串聯在各類實現中以線性時間發生。

像None這樣的單身人士的比較應該老是用「 是」或「 不是」來進行，歷來就不是平等運算符。

另外，若是x的意思是x不是None，那麼要當心寫x。例如，當測試一個變量或默認爲None的參數是否設置爲其餘值時。另外一個值可能有一個類型（如容器），在布爾上下文中可能爲false！

使用不是操做員而不是...是。雖然這兩個表達式在功能上是相同的，但前者更具可讀性而且更受歡迎。