--<<PEP 0008 -- Style Guide for Python Code>>

令人討厭的小人物身上有著愚蠢的一致性

--(A Foolish Consistency is the Hobgoblin of Little Minds)

• 代碼的統一是為了增強可讀性，因此一個項目中代碼風格的統一很重要；

• 知道什么時候統一，什么時候不統一，觀察不同的樣例，選出自己喜歡的，多質疑，多探索；

• 不打破向后兼容的特性正符合PEP8的特性；

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

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

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

• 因為殘留問題的代碼先于引入準則而單程，而此時沒有其他理由來修改這些代碼；

• 當代碼需要保持與舊版本的Python的功能兼容,但代碼卻是風格指南不支持推薦的。

代碼布局

--(Code lay-out)

(縮進)Indentation

<pre><code>Yes(正確):

Aligned with opening delimiter.

foo = long_function_name(var_one, var_two,
var_three, var_four)

More indentation included to distinguish this from the rest.

def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)

Hanging indents should add a level.

foo = long_function_name(
var_one, var_two,
var_three, var_four)

No（錯誤）:

Arguments on first line forbidden when not using vertical alignment.

foo = long_function_name(var_one, var_two,
var_three, var_four)

Further indentation required as indentation is not distinguishable.

def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)`</code></pre>

對連續的行來說，空格4是可選的

--(The 4-space rule is optional for continuation lines.)

<pre><code>Optional:

Hanging indents may be indented to other than 4 spaces.(懸掛縮進不同于空格4)

foo = long_function_name(
var_one, var_two,
var_three, var_four)

當條件語句 if -statement 太長而需要多行顯示的時候, 標記組合關鍵、增加一個空格、增加半開始括號、每行添加4-空格是很有價值的。這樣可
能會產生if -statement中那些前面同樣添加了4-空格的嵌套式語句的視覺沖突。PEP的做法沒有很好的解決上述存在的嵌套語句的視覺混淆問題，
下面的樣例中給出了一些可接受的做法，當然不僅限于此:

No extra indentation.

if (this_is_one_thing and
that_is_another_thing):
do_something()

Add a comment, which will provide some distinction in editors

supporting syntax highlighting.

if (this_is_one_thing and
that_is_another_thing):
# Since both conditions are true, we can frobnicate.
do_something()

Add some extra indentation on the conditional continuation line.

if (this_is_one_thing
and that_is_another_thing):
do_something()

閉合的另一半括號/中括號/大括號，可以與列表中最后一行第一個非空格元素對齊，如下：

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',
)</code></pre>

(Tabs還是空格)Tabs or Spaces?

--空格space是縮進(indentation)的首選;

--Tabs，一般如果一開始就試圖用tab鍵來實現縮進，后面才會繼續用tab來唯一的實現縮進;

--python3不允許混合使用space和tab;

--python2傾向于將混合使用的space和tab轉換為唯一的spqce;

最大代碼行長度

--(Maximum Line Length)

--限制每行字符的最大長度為79個字符

--對于結構限制較少的文本字符串和注釋，限定長度為72個字符

--可以根據開發團隊適時需求，修改限定長度在80-100之間，但是文本字符串和注釋還是72比較好

--可以使用轉義字符\拼接，用例如下：
<pre><code>with open('/path/to/some/file/you/want/to/read') as file_1,
open('/path/to/some/file/being/written', 'w') as file_2:
file_2.write(file_1.read())

class Rectangle(Blob):

def __init__(self, width, height,
             color='black', emphasis=None, highlight=0):
    if (width == 0 and height == 0 and
            color == 'red' and emphasis == 'strong' or
            highlight > 100):
        raise ValueError("sorry, you lose")
    if width == 0 and height == 0 and (color == 'red' or
                                       emphasis is None):
        raise ValueError("I don't think so -- values are %s, %s" %
                         (width, height))
    Blob.__init__(self, width, height,
                  color, emphasis, highlight)</code></pre>

空行

--(Blank Lines)

--頂層函數和類的定義之間要空兩行；

--類中的方法定義間要空一行；

--額外的空行可被用于 (保守的 (sparingly)) 分割相關函數群 (groups of related functions)。在一組相關的單句 (related one-liners) 中間可以省略空行 (例如一組啞元 (dummy implementations))；

--在函數中使用空行時，請謹慎的用于表示一個邏輯段落 (logical sections)；

--Python 接受 contrl-L (即 ^L) 換頁符作為空白符 (whitespace)；許多工具視這些 字符為分頁符 (page separators)，因此在你的文件中，可以用它們來為相關片段 (sections) 分頁;

源文件編碼

--(Source File Encoding)

--Python 核心發布中的代碼應該始終使用 ASCII 或 Latin-1 編碼(又名ISO-8859-1)。

--使用ASCII的文件不必有譯碼 cookie (coding cookie)。 Latin-1 僅當注釋或文檔字 符串涉及作者名字需要 Latin-1 時才被使用；另外使用 \x 轉義字符是在字符串中包 含非 ASCII 數據的首選方法。

導入

--(imports)

• -通常應該在單獨的行中導入，例如：
  <pre><code>Yes:
  import os
  import sys
  No:
  import sys, os
  但是這樣也是可以的：
  from subprocess import Popen, PIPE
  -- Imports 通常被放置在文件的頂部，僅在模塊注釋和文檔字符串之后，在模塊的全局變量和常量之前。
  Imports應該按照如下順序成組安放：
  1 標準庫的導入
  2 相關的第三方包的導入
  3 本地應用/庫的特定導入
  你應該在每組導入之間放置一個空行。
  把任何相關 all 說明的放在 imports 之后。
  對于內部包的導入是非常不推薦使用相對導入的。對所有導入總是使用包的絕對路徑。即使現在 PEP 328 7 在 Python 2.5 中被完整實現了，
  其 explicit relative imports 的風格也是不推薦的。絕對導入能更好的移植 (portable)，通 常也更易讀;
  從一個包含類的模塊中導入類時，通常可以寫成這樣：
  from myclass import MyClass
  from foo.bar.yourclass import YourClass
  如果這樣寫導致了本地名字沖突，那么就這樣寫：
  import myclass import foo.bar.yourclass
  并使用 "myclass.MyClass" and "foo.bar.yourclass.YourClass"</code></pre>

無傷大雅的小問題

--(Pet Peeves)

• 在以下情況盡量避免多余的空格:

  在括號，中括號，大括號內.

  <pre><code>Yes: spam(ham[1], {eggs: 2})
  No: spam( ham[ 1 ], { eggs: 2 } )</code></pre>

  在逗號，分號，句號前:

  <pre><code>Yes: if x == 4: print x, y; x, y = y, x
  No: if x == 4 : print x , y ; x , y = y , x</code></pre>

  當分片的時候，在[]中，冒號相當于一個二目運算符，而且具有在任一側等價的位置，所有冒號必須有相同分量的空格，當然，當分片中分號兩側的參數缺省時，空格也缺省

  <pre><code>Yes:

  ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
  ham[lower:upper], ham[lower:upper:], ham[lower::step]
  ham[lower+offset : upper+offset]
  ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
  ham[lower + offset : upper + offset]
  No:

  ham[lower + offset:upper + offset]
  ham[1: 9], ham[1 :9], ham[1:9 :3]
  ham[lower : : upper]
  ham[ : upper]</code></pre>

  在左括號與函數名間

  <pre><code>Yes: spam(1)
  No: spam (1)</code></pre>

  在左中括號與參數名間:

  <pre><code>Yes: dct['key'] = lst[index]
  No: dct ['key'] = lst [index]</code></pre>

  定義變量的時候，變量名與賦值操作符之間多于一個空格.

  <pre><code>Yes:

  x = 1
  y = 2
  long_variable = 3
  No:

  x = 1
  y = 2
  long_variable = 3</code></pre>

其他建議

--(Other Recommendations)

• 始終在這些二元運算符兩邊放置一個空格:

  assignment (=),
  augmented assignment (+=, -= etc.),
  comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not),
  Booleans (and, or, not)

• 在數學運算符兩邊使用空格：

  <pre><code>Yes:
  i = i + 1 submitted += 1 x = x 2 - 1 hypot2 = x x + y y c = (a + b) (a - b)
  No:
  i=i+1 submitted +=1 x = x2 - 1 hypot2 = xx + y*y c = (a+b) (a-b)</code></pre>

• 不要在用于指定關鍵字參數 (keyword argument) 或默認參數值的 '=' 號周圍使用空格。

  <pre><code>Yes:
  def complex(real, imag=0.0):
  return magic(r=real, i=imag)
  No:
  def complex(real, imag = 0.0):
  return magic(r = real, i = imag)</code></pre>

• 復合語句 (Compound statements) (多條語句寫在同一行) 一般不推薦。

  <pre><code>Yes:
  if foo == 'blah':
  do_blah_thing()
  do_one()
  do_two()
  do_three()

  Rather not:
  if foo == 'blah': do_blah_thing() do_one(); do_two(); do_three()</code></pre>

• 雖然有時可以在 if/for/while 的同一行跟一小段代碼，但絕不要對多條子句
  (multi-clause statements) 也這樣做。也避免折疊這樣的長行。

  <pre><code>最好不要 (Rather not)：
  if foo == 'blah': do_blah_thing()
  for x in lst: total += x
  while t < 10: t = delay()

  明確不要 (Definitely not)：
  if foo == 'blah': do_blah_thing()
  else: do_non_blah_thing()
  try: something()
  finally: cleanup()

  do_one(); do_two(); do_three(long, argument,
  list, like, this)
  if foo == 'blah': one(); two(); three()</code></pre>

注釋

--(Comments)

--同代碼不一致的注釋比沒注釋更差,當代碼修改時，始終優先更新注釋;
--注釋應該是完整的句子，如果注釋是一個短語或句子，首字母應該大寫，除非它是一 個以小寫字母開頭的標識符 (永遠不要修改標識符的大小寫);
--如果注釋很短，可以省略末尾的句號，注釋塊通常由一個或多個段落組成，段落是由完整的句子構成的，每個句子應該以句號結尾；
--你應該在結束語句的句點 (a sentence-ending period) 后使用兩個空格；
--用英語書寫時，斷詞和空格是可用的 (When writing English, Strunk and White apply);；
--非英語國家的 Python 程序員：請用英語書寫你的注釋，除非你 120% 的確信代碼永遠不會被不懂你的語言的人閱讀；

• 塊注釋(Block Comments)

<pre>--注釋塊通常應用于跟隨其后的一些 (或者全部) 代碼，并和這些代碼有著相同的縮進 層次。注釋塊中每行以 '#' 和一個空格開始
(除非它是注釋內的縮進文本),注釋塊內的段落以僅含單個 '#' 的行分割；</pre>

• 行內注釋(Inline Comments)

<pre><code>節儉使用行內注釋。
一個行內注釋是和語句在同一行的注釋，行內注釋應該至少用兩個空格和語句分開，它們應該以一個 '#' 和單個空格開始；
行內注釋不是必需的，事實上，如果說的是顯而易見事，還會使人分心，不要這樣做：

x = x + 1 # Increment x

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

x = x + 1 # Compensate for border</code></pre>

• 文本字符串(Documentation Strings)

書寫好的文檔字符串 (又名"docstrings") 的約定，在 PEP 257中是永存的。

為所有公共模塊、函數、類和方法書寫文檔字符串。文檔字符串對非公開的方法不
是必要的，但你應該有一條注釋來描述這個方法做什么；這條注釋應該出現在 "def" 行之后。
PEP 257 描述了好的文檔字符串約定。一定注意，多行文檔字符串結尾的 """ 應該
單獨成行，并推薦在其前加一空行，例如：
<pre><code>
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
對單行的文檔字符串，結尾的 """ 在同一行也可以。</code></pre>

版本注記

--(Version Bookkeeping)

如果你用Subversion, CVS, or RCS管理你的代碼文件, 可以參照下面的做法：

<pre><code>version = "$Revision$"

$Source$

這幾行文字可以加在模塊中文本字符串的后面，用空格與其余代碼部分分開</code></pre>

命名慣例

--(Naming Conventions)

• 首要原則(Overriding Principle)
  對公眾可見的，如API中的命名，應當優先考慮名字反映其用途，而非應用；

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

  • 單個小寫字母 (b)
  • 單個大寫字母 (B)
  • 小寫串 (lowercase)
  • 帶下劃線的小寫串 (lower_case_with_underscores)
  • 大寫串 (UPPERCASE)
  • 帶下劃線的大寫串 (UPPER_CASE_WITH_UNDERSCORES)
  • 首字母大寫單詞串 (CapitalizedWords) (或 CapWords、CamelCase -- 因其字母看起來錯落有致，故得此名)。有時這也被稱作StudlyCaps。
    注意: 在 CapWords 中使用縮寫，需要把縮寫的所有字母大寫。故 HTTPServerError 比 HttpServerError 更好。
  • 混合大小寫串 (mixedCase) (與首字母大寫串不同之處在于第一個字符是小寫的！)
  • 帶下劃線的首字母大寫串 (Capitalized_Words_With_Underscores) (丑陋！)

  還有一種風格，使用特別的短前綴來將相關的名字分成組。這在 Python 中不常用， 但是出于完整性要提一下。例如，os.stat() 函數返回
  一個 tuple，其元素傳統上有 象 st_mode, st_size, st_mtime 等等這樣的名字。(這樣做是為了強調與 POSIX 系 統調用結構體的相關
  性，這有助于程序員熟悉那些相關性。)X11 庫的所有公開函數以 X 開頭。在 Python 中，這個風格通常認為是不必要的，因 為屬性和方法
  名以對象作前綴，而函數名以模塊名作前綴。
  另外，以下用前導或后置下劃線的特殊形式是被公認的 (通常這些可以和任何習慣相 組合):

  • single_leading_underscore:
    (單前導下劃線): 弱的 "內部使用 (internal use)" 標志。 例如，"from M import " 不會導入以下劃線開頭的對象。
  • single_trailing_underscore:
    (單后置下劃線): 習慣上用于避免與 Python 關鍵詞的沖突。 例如： Tkinter.Toplevel(master, class='ClassName')
  • double_leading_underscore:
    (雙前導下劃線): 當用于命名 class 屬性時，會觸發名字重整 (name mangling)。 (在類 FooBar 中，boo 變成 FooBarboo；參加下面)。
  • double_leading_and_trailing_underscore:
    (雙前導和后置下劃線)：存在于用戶控制的 (user-controlled) 名字空間的 "magic" 對象或屬性。例如: init, import or file 決不
    要發明這樣的名字，僅像文檔中那樣使用即可。</code></pre>

• 命名風格說明
  <pre><code>--避免采用的名字 (Names to Avoid)<pre><code>1 決不要用字符 'l' (小寫字母 el)，'O' (大寫字母 oh)，或 'I' (大寫字母 eye) 作為單個字符的變量名。
  2 在一些字體中，這些字符不能與數字 1 和 0 區別開。當想要使用 'l' 時，用'L' 代替它。</code></pre>
  --包和模塊名 (Package and Module Names)<pre><code>1 模塊名應該是簡短的、全部小寫的名字。可以在模塊名中使用下劃線以提高可讀性 。
  2 Python 包名也應該是簡短的、全部小寫的名字，盡管不推薦使用下劃線。
  3 因為模塊名被映射到文件名，有些文件系統大小寫不敏感并且截短長名字，所以把 模塊名選擇為相當短就很重要了
  這在 Unix 上不是問題，但當把代碼遷移到 Mac、Windows 或 DOS 上時，就可能是個問題了。當一個用 C 或 C++ 寫的擴展模塊，
  有一個伴隨的 Python 模塊來提供一個更高層 (例如，更面向對象) 的接口時，C/C++ 模塊名有一個前導下劃線 (如：socket)。</code></pre>
  --類名 (Class Names)<pre><code>幾乎沒有例外，類名使用首字母大寫單詞串 (CapWords) 的約定。 內部使用的類使用一個額外的前導下劃線。</code></pre>
  --異常名 (Exception Names)<pre><code>因為異常應該是類，故類命名約定也適用于異常。然而，你應該對異常名添加后綴 "Error" (如果該異常的確是一個錯誤)。</code></pre>
  --全局變量名 (Global Variable Names)<pre><code>(讓我們希望這些變量只打算用于一個模塊內部。) 這些約定與那些用于函數的約定差不多。
  對設計為通過 "from M import " 來使用的模塊，應采用 all 機制來防止導 出全局變量；或者使用舊的約定，為該類全局變量加一個前導下劃線
  (可能你想表 明這些全局變量是 "module non-public")。</code></pre>
  --函數名 (Function Names)<pre><code>函數名應該為小寫，必要時可用下劃線分隔單詞以增加可讀性。
  混合大小寫 (mixedCase) 僅被允許用于這種風格已經占優勢的上下文 (如: threading.py)，以便保持向后兼容。</code></pre>
  --函數和方法的參數 (Function and method arguments)<pre><code>1 對實例的方法，總是用 'self' 做第一個參數。
  2 對類的方法，總是用 'cls' 做第一個參數。
  如果函數的參數名與保留關鍵字沖突，在參數名后加一個下劃線，比用縮寫、錯誤 的拼寫要好。因此 "print" 比 "prnt" 好。
  (也許使用同義詞來避免沖突更好。)</code></pre>
  --方法名和實例變量 (Method Names and Instance Variables)<pre><code>1 采用函數命名規則：小寫單詞，必要時可用下劃線分隔單詞以增加可讀性。
  2 僅對 non-public 方法和實例變量采用一個前導下劃線。
  3 為避免與子類命名沖突，采用兩個前導下劃線來觸發 Python 的命名重整規則。
  4 Python 用類名重整這些名字：如果類 Foo 有一個屬性名為 a， 它不能以 Foo.a 訪問。(執著的用戶還是可以通過 Foo.Fooa 得到訪問權。)
  通常，雙 前導下劃線僅被用來避免與基類的屬性發生名字沖突。
  注：關于 names 的作用存在一些爭論 (見下面)。</code></pre>
  --常量(Constants)<pre><code>常量通常是在模塊級下定義并寫入，常使用大寫字母和下劃線，其中下劃線分隔單詞。
  例子包括MAX_OVERFLOW和TOTAL。</code></pre>
  --繼承的設計 (Designing for inheritance)<pre><code>1 總是確定類的方法和實例變量 (統稱為屬性) 是否應該被公開或者不公開。
  如果有 疑問，選擇不公開；今后把其改為公開比把一個公開屬性改為非公開要容易。
  2 公開屬性是那些你期望你的類的不相關的客戶使用，并根據你的承諾來避免向后不 兼容變更。非公開屬性是那些確定不給第三方使用的；
  你不保證非公開屬性不變,甚至被移除。這里我們不使用術語 "private"，因為在 Python 中沒有屬性是真正私有的
  (沒有 通常的無用功 (unnecessary amount of work))。
  3 另一類屬性是 "subclass API" 的一部分 (在其他語言中通常稱為 "protected")。 一些類被設計為基類，要么被擴展，要么類的某些行為被修改。
  當設計這樣的類時,注意明確決定哪些屬性是公開的，哪些是子類 API 的一部分，及哪些是真正僅被 你的基類使用。
  謹記這些 Python 特色的指導方針：
  公開屬性應該沒有前導下劃線。
  如果公開屬性名和保留關鍵字沖突，在你的屬性名后添加一個后置下劃線。這比
  縮寫或者錯誤的拼寫更可取。(然而，盡管這條規則，對任何已知是類的變量或者 參數，尤其是類方法的第一個參數，'cls' 是首選拼寫方式。)
  注1：參見上面對類方法的參數名的建議。
  對簡單的公開數據屬性 (data attribute)，最好只暴露屬性名，沒有復雜的訪問
  /修改方法 (accessor/mutator methods)。謹記 Python 為將來增強提供了一條 容易的途徑，
  你應該發現簡單數據屬性需要增加功能行為。在那種情況，
  用特性 (properties) 把功能實現隱藏在簡單數據屬性訪問語法后面。
  注1：特性僅工作于 new-style 的類。
  注2：嘗試不管功能行為的副作用，盡管像 cache 之類副作用通常是好的。
  注3：避免對費時的計算操作使用特性；屬性符號使調用者相信訪問是 (相對)
  廉價的。
  如果確定你的類會被子類化，并且你有不希望子類使用的屬性，考慮用兩個前導
  下劃線、但沒有后置下劃線命名它們。這將觸發 Python 的名字重整算法，把類 名整合進屬性名中。當子類無意中包含了相同名字的屬性時，
  這有助于避免屬性 名沖突。
  注1：注意僅使用簡單類名來重整名字，因此，如果子類使用相同的類名和屬性名
  ，你仍然會名字沖突。
  注2：名字重整使一些應用稍有不便，例如調試和 getattr()。然而名字重整
  算法有良好的文檔，也容易手工執行。
  注3：不是每個人都喜歡名字重整。嘗試在避免意外的名字沖突需求和高級調用者
  的可能應用之間平衡。</code></pre>
  </code></pre>

編程建議

--(Programming Recommendations)

代碼應該按照一種方式編寫，但是不應該不利于在其他python中的應用 (PyPy, Jython, IronPython, Cython, Psyco, and such).

例如，對 a+=b or a=a+b 形式的語句，不要依賴 CPython 對就地 (in-place) 字 符串連接的高效實現。那些語句在 Jython 中運行很慢。對庫的性能敏感部分，應 該改用 ''.join() 語句。這將保證對不同的實現，字符串連接表現為線性時間。

與 None 之類的單件比較，應該總是用 'is' or 'is not'，絕不要用等號操作符。

同樣，當你本意是 "if x is not None" 時，對寫成 "if x" 要小心 -- 例如，當 測試一個默認為 None 的變量或參數是否被設置為其他值時,這個其他值可能是一種 在布爾上下文中為假的類型 (例如容器)！

使用is not而不是not ... is，雖然兩者表述的功能相同，但是前者的可讀性和鐘愛度更高

<pre><code>Yes:

if foo is not None:
No:

if not foo is None:</code></pre>

當使用一些比較的操作命令時，最好能夠用以下6中操作( eq , ne , lt , le , gt , ge ) 而不是依賴其他的一些比較方法。

為了減小關聯性，functools.total_ordering()提供生成了一些缺失的比較方法。

PEP 207假定Python具有自反性，因此解釋器可能交換 y > x 成 x < y , y >= x 成 x <= y , 又或者把 x == y 轉換成 x != y。sort() 與min()操作是基于 < 運算符，max()函數使用 > 運算符。然而, 最好是使用上述的六種方式，這樣不會增加在其他文本中的混淆。

使用def-statement比綁定一個lambda表達式的assignment-statement要好

<pre><code>Yes:

def f(x): return 2*x
No:

f = lambda x: 2*x</code></pre>

other example

<pre><code>Yes:

try:
value = collection[key]
except KeyError:
return key_not_found(key)
else:
return handle_value(value)
No:

try:
# Too broad!
return handle_value(collection[key])
except KeyError:
# Will also catch KeyError raised by handle_value()
return key_not_found(key)</code></pre>

<pre><code>Yes:

with conn.begin_transaction():
do_stuff_in_transaction(conn)
No:

with conn:
do_stuff_in_transaction(conn)</code></pre>

<pre><code>Yes:

def foo(x):
if x >= 0:
return math.sqrt(x)
else:
return None

def bar(x):
if x < 0:
return None
return math.sqrt(x)
No:

def foo(x):
if x >= 0:
return math.sqrt(x)

def bar(x):
if x < 0:
return
return math.sqrt(x)</code></pre>

<pre><code>Yes: if foo.startswith('bar'):
No: if foo[:3] == 'bar':
Object type comparisons should always use isinstance() instead of comparing types directly.</code></pre>

<pre><code>Yes: if isinstance(obj, int):

No: if type(obj) is type(1):</code></pre>

<pre><code>Yes: if not seq:
if seq:

No: if len(seq)
if not len(seq)</code></pre>

<pre><code>Yes: if greeting:
No: if greeting == True:
Worse: if greeting is True:</code></pre>