這篇文檔所給出的編碼約定適用于在主要的Python發布版本中組成標準庫的Python代碼，請查閱相關的關于在Python的C實現中C代碼風格指南的描述。

這篇文檔改編自Guido最初的《Python風格指南》一文，并從《Barry'sstyleguide》中添加了部分內容。在有沖突的地方，Guide的風格規則應該是符合本PEP的意圖(譯注：指當有沖突時，應以Guido風格為準)。這篇PEP仍然尚未完成(實際上，它可能永遠都不會完成)。

在這篇風格指導中的一致性是重要的。在一個項目內的一致性更重要。在一個模塊或函數內的一致性最重要。但最重要的是：知道何時會不一致——有時只是沒有實施風格指導。當出現疑惑時，運用你的最佳判斷，看看別的例子，然后決定怎樣看起來更好。并且要不恥下問!

打破一條既定規則的兩個好理由：

(1)當應用這個規則是將導致代碼可讀性下降，即便對某人來說，他已經習慣于按這條規則來閱讀代碼了。

(2)為了和周圍的代碼保持一致而打破規則(也許是歷史原因)，雖然這也是個清除其它混亂的好機會(真正的XP風格)。

代碼的布局

縮進

使用Emacs的Python-mode的默認值：4個空格一個縮進層次。對于確實古老的代碼，你不希望產生混亂，可以繼續使用8空格的制表符(8-spacetabs)。EmacsPython-mode自動發現文件中主要的縮進層次，依此設定縮進參數。

制表符還是空格

永遠不要混用制表符和空格。最流行的Python縮進方式是僅使用空格，其次是僅使用制表符，混合著制表符和空格縮進的代碼將被轉換成僅使用空格。(在Emacs中，選中整個緩沖區，按ESC-x去除制表符。)調用Python命令行解釋器時使用-t選項，可對代碼中不合法得混合制表符和空格發出警告，使用-tt時警告將變成錯誤。這些選項是被高度推薦的。

對于新的項目，強烈推薦僅使用空格而不是制表符。許多編輯器擁有使之易于實現的功能(在Emacs中，確認indent-tabs-mode是nil)。

行的最大長度

周圍仍然有許多設備被限制在每行80字符：而且，窗口限制在80個字符。使將多個窗口并排放置成為可能。在這些設備上使用默認的折疊方式看起來有點丑陋。因此，請將所有行限制在最大79字符(Emacs準確得將行限制為長80字符)，對順序排放的大塊文本(文檔字符串或注釋)，推薦將長度限制在72字符。

折疊長行的首選方法是使用Pyhon支持的圓括號，方括號和花括號內的行延續。如果需要，你可以在表達式周圍增加一對額外的圓括號，但是有時使用反斜杠看起來更好，確認恰當得縮進了延續的行。

Emacs的Python-mode正確得完成了這些。一些例子：

#!Python

classRectangle(Blob)：

def__init__(self，width，height，color='black'，emphasis=None，highlight=0)：

ifwidth==0andheight==0and/

color=='red'andemphasis=='strong'or/

highlight>100：

raiseValueError，"sorry，youlose"

ifwidth==0andheight==0and(color=='red'or

emphasisisNone)：

raiseValueError，"Idon'tthinkso"

Blob.__init__(self，width，height，color，emphasis，highlight)

空行

用兩行空行分割頂層函數和類的定義，類內方法的定義用單個空行分割，額外的空行可被用于(保守的)分割相關函數組成的群，在一組相關的單句中間可以省略空行。(例如：一組啞元素)。

當空行用于分割方法的定義時，在‘class'行和第一個方法定義之間也要有一個空行。在函數中使用空行時，請謹慎的用于表示一個邏輯段落。Python接受contol-L(即^L)換頁符作為空格：Emacs(和一些打印工具)，視這個字符為頁面分割符，因此在你的文件中，可以用他們來為相關片段分頁。

編碼

Python核心發布中的代碼必須始終使用ASCII或Latin-1編碼(又名ISO-8859-1)，使用ASCII的文件不必有編碼cookie，Latin-1僅當注釋或文檔字符串涉及作者名字需要Latin-1時才被使用：

另外使用/x轉義字符是在字符串中包含非ASCII(non-ASCII)數據的首選方法。

作為PEP263實現代碼的測試套件的部分文件是個例外。

導入

通常應該在單獨的行中導入(Imports)，例如：

No：importsys，os

Yes：importsys

importos

但是這樣也是可以的：

fromtypesimportStringType，ListType

Imports通常被放置在文件的頂部，僅在模塊注釋和文檔字符串之后，在模塊的全局變量和常量之前。Imports應該有順序地成組安放：

1、標準庫的導入(Imports)

2、相關的主包(majorpackage)的導入(即，所有的email包在隨后導入)

3、特定應用的導入(imports)

你應該在每組導入之間放置一個空行，對于內部包的導入是不推薦使用相對導入的，對所有導入都要使用包的絕對路徑。

從一個包含類的模塊中導入類時，通常可以寫成這樣：

fromMyClassimportMyClass

fromfoo.bar.YourClassimportYourClass

如果這樣寫導致了本地名字沖突，那么就這樣寫

importMyClass

importfoo.bar.YourClass

即使用"MyClass.MyClass"和"foo.bar.YourClass.YourClass"

表達式和語句中的空格

Guido不喜歡在以下地方出現空格：

緊挨著圓括號，方括號和花括號的，如："spam(ham[1]，{eggs：2})"。要始終將它寫成"spam(ham[1]，{eggs：2})"。

緊貼在逗號，分號或冒號前的，如：

"ifx==4：printx，y：x，y=y，x"。要始終將它寫成

"ifx==4：printx，y：x，y=y，x"。

緊貼著函數調用的參數列表前開式括號(openparenthesis)的，如"spam(1)"。要始終將它寫成"spam(1)"。

緊貼在索引或切片，開始的開式括號前的，如：

"dict['key']=list[index]"。要始終將它寫成"dict['key']=list[index]"。

在賦值(或其它)運算符周圍的用于和其它并排的一個以上的空格，如：

#!Python

x=1

y=2

long_variable=3

要始終將它寫成

#!Python

x=1

y=2

long_variable=3

(不要對以上任意一條和他爭論——Guido養成這樣的風格超過20年了。)

其它建議

始終在這些二元運算符兩邊放置一個空格：賦值(=)，比較(==，<，>，!=，<>，<=，>=，in，notin，is，isnot)，布爾運算(and，or，not)。

按你的看法在算術運算符周圍插入空格。始終保持二元運算符兩邊空格的一致。

一些例子：

#!Python

i=i+1

submitted=submitted+1

x=x*2-1

hypot2=x*x+y*y

c=(a+b)*(a-b)

c=(a+b)*(a-b)

不要在用于指定關鍵字參數或默認參數值的'='號周圍使用空格，例如：

#!Python

defcomplex(real，imag=0。0)：

returnmagic(r=real，i=imag)

不要將多條語句寫在同一行上：

No：iffoo=='blah'：do_blah_thing()

Yes：iffoo=='blah'：

do_blah_thing()

No：do_one()：do_two()：do_three()

Yes：do_one()

do_two()

do_three()

注釋

同代碼不一致的注釋比沒注釋更差。當代碼修改時，始終優先更新注釋!注釋應該是完整的句子，如果注釋是一個短語或句子，首字母應該大寫，除非他是一個以小寫字母開頭的標識符(永遠不要修改標識符的大小寫)。

如果注釋很短，最好省略末尾的句號。注釋塊通常由一個或多個由完整句子構成的段落組成，每個句子應該以句號結尾。你應該在句末，句號后使用兩個空格，以便使Emacs的斷行和填充工作協調一致。

用英語書寫時，斷詞和空格是可用的。非英語國家的Python程序員：請用英語書寫你的注釋，除非你120%的確信這些代碼不會被不懂你的語言的人閱讀。

注釋塊

注釋塊通常應用于跟隨著一些(或者全部)代碼并和這些代碼有著相同的縮進層次。注釋塊中每行以‘#'和一個空格開始(除非他是注釋內的縮進文本)。注釋塊內的段落以僅含單個‘#'的行分割。注釋塊上下方最好有一空行包圍(或上方兩行下方一行，對一個新函數定義段的注釋)。

行內注釋

一個行內注釋是和語句在同一行的注釋，行內注釋應該謹慎適用，行內注釋應該至少用兩個空格和語句分開，它們應該以'#'和單個空格開始。

x=x+1#Incrementx

如果語意是很明了的，那么行內注釋是不必要的，事實上是應該被移除的。不要這樣寫：

x=x+1#Incrementx

x=x+1#Compensateforborder

但是有時，這樣是有益的：

x=x+1#Compensateforborder

文檔字符串

應該一直遵守編寫好的文檔字符串的約定PEP257[3]。為所有公共模塊，函數，類和方法編寫文檔字符串。文檔字符串對非公開的方法不是必要的，但你應該有一個描述這個方法做什么的注釋。這個注釋應該在"def"這行后。

PEP257描述了好的文檔字符串的約定。一定注意，多行文檔字符串結尾的"""應該單獨成行，例如：

"""Returnafoobang

Optionalplotzsaystofrobnicatethebizbazfirst。

"""

對單行的文檔字符串，結尾的"""在同一行也可以。

版本注記

如果你要將RCS或CVS的雜項(crud)包含在你的源文件中，按如下做。

#!Python

__version__="$Revision：1。4$"

#$Source：E：/cvsroot/Python_doc/pep8。txt，v$

這個行應該包含在模塊的文檔字符串之后，所有代碼之前，上下用一個空行分割。

命名約定

Python庫的命名約定有點混亂，所以我們將永遠不能使之變得完全一致，不過還是有公認的命名規范的。新的模塊和包(包括第三方的框架)必須符合這些標準，但對已有的庫存在不同風格的，保持內部的一致性是首選的。

描述：命名風格

有許多不同的命名風格。以下的有助于辨認正在使用的命名風格，獨立于它們的作用。以下的命名風格是眾所周知的：

b(單個小寫字母)

B(單個大寫字母)

Lowercase(小寫)

lower_case_with_underscores(有下劃線的小寫)

UPPERCASE(大寫)

UPPER_CASE_WITH_UNDERSCORES(有下劃線的大寫)

CapitalizedWords(或CapWords，CamelCase這樣命名是因為可從字母的大小寫分出單詞。這有時也被當作StudlyCaps。

mixedCase(與CapitalizedWords的不同在于首字母小寫!)

Capitalized_Words_With_Underscores(有下劃線的首字母大寫)(丑陋!)

還有用短的特別前綴將相關的名字聚合在一起的風格。這在Python中不常用，但是出于完整性要提一下，例如，os.stat()函數返回一個元組，他的元素傳統上說名如st_mode，st_size，st_mtime等等。

X11庫的所有公開函數以X開頭。(在Python中，這個風格通常認為是不必要的，因為屬性和方法名以對象作前綴，而函數名以模塊名作前綴。)

另外，以下用下劃線作前導或結尾的特殊形式是被公認的(這些通常可以和任何習慣組合)：

_single_leading_underscore(單個下劃線作前導)：弱的“內部使用(internaluse)”標志。(例如，“fromMimport*”不會導入以下劃線開頭的對象)。

single_trailing_underscore_(單個下劃線結尾)：用于避免與Python關鍵詞的沖突，例如：“Tkinter.Toplevel(master，class_='ClassName')”。

_double_leading_underscore(雙下劃線)：從Python1.4起為類私有名。

_double_leading_and_trailing_underscore_：“magic”對象或屬性，存在于用戶控制的(user-controlled)名字空間，例如：_init_，_import_或_file_。有時它們被用戶定義用于觸發某個魔法行為(例如：運算符重載)：有時被構造器插入，以便自己使用或為了調試。因此，在未來的版本中，構造器(松散得定義為Python解釋器和標準庫)可能打算建立自己的魔法屬性列表，用戶代碼通常應該限制將這種約定作為己用。欲成為構造器的一部分的用戶代碼可以在下滑線中結合使用短前綴，例如：

_bobo_magic_attr__。

說明：命名約定

應避免的名字。永遠不要用字符‘l'(小寫字母el(就是讀音，下同))，‘O'(大寫字母oh)，或‘I'(大寫字母eye)作為單字符的變量名。在某些字體中這些字符不能與數字1和0分辨。試著在使用‘l'時用‘L'代替。

模塊名

模塊應該是不含下劃線的，簡短的，小寫的名字。因為模塊名被映射到文件名，有些文件系統大小寫不敏感并且截短長名字，模塊名被選為相當短是重要的，這在Unix上不是問題，但當代碼傳到Mac或Windows上就可能是個問題了。

當用C或C++編寫的擴展模塊有一個伴隨Python模塊提供高層(例如進一步的面向對象)接口時，C/C++模塊有下劃線前導(如：_socket)。Python包應該是不含下劃線的，簡短的，全小寫的名字。

類名

幾乎不出意料，類名使用CapWords約定。內部使用的類外加一個前導下劃線。

異常名

如果模塊對所有情況定義了單個異常，它通常被叫做“error”或“Error”。似乎內建(擴展)的模塊使用“error”(例如：os.error)，而Python模塊通常用“Error”(例如：xdrlib.Error)。趨勢似乎是傾向使用CapWords異常名。

全局變量名

(讓我們祈禱這些變量僅在一個模塊的內部有意義)

這些約定和在函數中的一樣。模塊是被設計為通過“fromMimport*”來使用的，必須用一個下劃線作全局變量(及內部函數和類)的前綴防止其被導出(exporting)。

函數名

函數名應該為小寫，可能用下劃線風格單詞以增加可讀性。mixedCase僅被允許用于這種風格已經占優勢的上下文(如：threading.py)，以便保持向后兼容。

方法名和實例變量

這段大體上和函數相同：通常使用小寫單詞，必要時用下劃線分隔增加可讀性。僅為不打算作為類的公共界面的內部方法和實例使用一個前導下劃線，Python不強制要求這樣：它取決于程序員是否遵守這個約定。

使用兩個前導下劃線以表示類私有的名字，Python將這些名字和類名連接在一起：

如果類Foo有一個屬性名為_a，它不能以Foo._a訪問。(固執的用戶還是可以通過Foo._Foo__a得到訪問權。)

通常雙前導下劃線僅被用于避免含子類的類中的屬性名的名字沖突。

繼承的設計

始終要確定一個類中的方法和實例變量是否要被公開。通常，永遠不要將數據變量公開，除非你實現的本質上只是記錄，人們幾乎總是更喜歡代之給出一個函數作為類的界面(Python2.2的一些開發者在這點上做得非常漂亮)。

同樣，確定你的屬性是否應為私有的。私有和非私有的區別在于模板將永遠不會對原有的類(導出類)有效，而后者可以。你應該在大腦中就用繼承設計好了你的類，私有屬性必須有兩個前導下劃線，無后置下劃線，非公有屬性必須有一個前導下劃線，無后置下劃線，公共屬性沒有前導和后置下劃線，除非它們與保留字沖突，在此情況下，單個后置下劃線比前置或混亂的拼寫要好，例如：class_優于klass。

最后一點有些爭議：如果相比class_你更喜歡klass，那么這只是一致性問題。

設計建議

單個元素(singletons)的比較，如None應該永遠用：‘is'或‘isnot'來做。當你本意是“ifxisnotNone”時，對寫成“ifx”要小心。例如當你測試一個默認為None的變量或參數是否被設置為其它值時，這個值也許在布爾上下文(Booleancontext)中是false!

基于類的異常總是好過基于字符串的異常。模塊和包應該定義它們自己的域內特定的基異常類，基類應該是內建的Exception類的子類。還始終包含一個類的文檔字符串。例如：

#!Python

classMessageError(Exception)：

"""Baseclassforerrorsintheemailpackage。"""

使用字符串方法(methods)代替字符串模塊，除非必須向后兼容Python2.0以前的版本。字符串方法總是非常快，而且和unicode字符串共用同樣的API(應用程序接口)在檢查前綴或后綴時避免對字符串進行切片。用startswith()和endswith()代替，因為它們是明確的并且錯誤更少。例如：

No：iffoo[：3]=='bar'：

Yes：iffoo。startswith('bar')：

例外是如果你的代碼必須工作在Python1.5.2(但是我們希望它不會發生!)，對象類型的比較應該始終用isinstance()代替直接比較類型，例如：

No：iftype(obj)istype(1)：

Yes：ifisinstance(obj，int)：

檢查一個對象是否是字符串時，緊記它也可能是unicode字符串!在Python2.3，str和unicode有公共的基類，basestring，所以你可以這樣做：

ifisinstance(obj，basestring)：

在Python2.2類型模塊為此定義了StringTypes類型，例如：

#!Python

fromtypesimportStringTypes

ifisinstance(obj，StringTypes)：

在Python2.0和2.1，你應該這樣做：

#!Python

fromtypesimportStringType，UnicodeType

ifisinstance(obj，StringType)or/

isinstance(obj，UnicodeType)：

對序列，(字符串，列表，元組)，使用空列表是false這個事實，因此“ifnotseq”或“ifseq”比“iflen(seq)”或“ifnotlen(seq)”好。書寫字符串文字時不要依賴于有意義的后置空格。這種后置空格在視覺上是不可辨別的，并且有些編輯器(特別是近來，reindent.py)會將它們修整掉。不要用==來比較布爾型的值以確定是True或False(布爾型是Pythn2.3中新增的)

No：ifgreeting==True：

Yes：ifgreeting：

No：ifgreeting==True：

Yes：ifgreeting：