本文部分提煉自書籍：《Effective Python》&《Python3 Cookbook》，但也做出了修改，并加上了作者自己的理解和運用中的最佳實踐。
全文約 9956 字，讀完可能需要 24 分鐘。原文鏈接：https://github.com/ecmadao/Coding-Guide
Pythonic
列表切割
list[start:end:step]
如果從列表開頭開始切割，那么忽略 start 位的 0，例如
list[:4]如果一直切到列表尾部，則忽略 end 位的 0，例如
list[3:]切割列表時，即便 start 或者 end 索引跨界也不會有問題
列表切片不會改變原列表。索引都留空時，會生成一份原列表的拷貝
列表推導式
使用列表推導式來取代
map和filter
不要使用含有兩個以上表達式的列表推導式
數據多時，列表推導式可能會消耗大量內存，此時建議使用生成器表達式
迭代
需要獲取 index 時使用
enumerateenumerate可以接受第二個參數，作為迭代時加在index上的數值
用
zip同時遍歷兩個迭代器
zip遍歷時返回一個元組
關于
for和while循環后的else塊循環正常結束之后會調用
else內的代碼循環里通過
break跳出循環，則不會執行else要遍歷的序列為空時，立即執行
else
反向迭代
對于普通的序列（列表），我們可以通過內置的reversed()函數進行反向迭代：
除此以外，還可以通過實現類里的__reversed__方法，將類進行反向迭代：
try/except/else/finally
如果
try內沒有發生異常，則調用else內的代碼else會在finally之前運行最終一定會執行
finally，可以在其中進行清理工作
函數
使用裝飾器
裝飾器用于在不改變原函數代碼的情況下修改已存在的函數。常見場景是增加一句調試，或者為已有的函數增加log監控
舉個栗子：
除此以外，還可以編寫接收參數的裝飾器，其實就是在原本的裝飾器上的外層又嵌套了一個函數：
但是像上面那樣使用裝飾器的話有一個問題：
也就是說原函數已經被裝飾器里的new_fun函數替代掉了。調用經過裝飾的函數，相當于調用一個新函數。查看原函數的參數、注釋、甚至函數名的時候，只能看到裝飾器的相關信息。為了解決這個問題，我們可以使用
Python 自帶的functools.wraps方法。
functools.wraps是個很 hack 的方法，它本事作為一個裝飾器，做用在裝飾器內部將要返回的函數上。也就是說，它是裝飾器的裝飾器，并且以原函數為參數，作用是保留原函數的各種信息，使得我們之后查看被裝飾了的原函數的信息時，可以保持跟原函數一模一樣。
此外，有時候我們的裝飾器里可能會干不止一個事情，此時應該把事件作為額外的函數分離出去。但是又因為它可能僅僅和該裝飾器有關，所以此時可以構造一個裝飾器類。原理很簡單，主要就是編寫類里的__call__方法，使類能夠像函數一樣的調用。
使用生成器
考慮使用生成器來改寫直接返回列表的函數
用這種方法有幾個小問題：
每次獲取到符合條件的結果，都要調用
append方法。但實際上我們的關注點根本不在這個方法，它只是我們達成目的的手段，實際上只需要index就好了返回的
result可以繼續優化數據都存在
result里面，如果數據量很大的話，會比較占用內存
因此，使用生成器generator會更好。生成器是使用yield表達式的函數，調用生成器時，它不會真的執行，而是返回一個迭代器，每次在迭代器上調用內置的next函數時，迭代器會把生成器推進到下一個yield表達式：
獲取到一個生成器以后，可以正常的遍歷它：
如果你還是需要一個列表，那么可以將函數的調用結果作為參數，再調用list方法
可迭代對象
需要注意的是，普通的迭代器只能迭代一輪，一輪之后重復調用是無效的。解決這種問題的方法是，你可以定義一個可迭代的容器類：
這樣的話，將類的實例迭代重復多少次都沒問題：
但要注意的是，僅僅是實現__iter__方法的迭代器，只能通過for循環來迭代；想要通過next方法迭代的話則需要使用iter方法：
使用位置參數
有時候，方法接收的參數數目可能不一定，比如定義一個求和的方法，至少要接收兩個參數：
對于這種接收參數數目不一定，而且不在乎參數傳入順序的函數，則應該利用位置參數*args：
但要注意的是，不定長度的參數args在傳遞給函數時，需要先轉換成元組tuple。這意味著，如果你將一個生成器作為參數帶入到函數中，生成器將會先遍歷一遍，轉換為元組。這可能會消耗大量內存：
使用關鍵字參數
關鍵字參數可提高代碼可讀性
可以通過關鍵字參數給函數提供默認值
便于擴充函數參數
定義只能使用關鍵字參數的函數
普通的方式，在調用時不會強制要求使用關鍵字參數
使用 Python3 中強制關鍵字參數的方式
使用 Python2 中強制關鍵字參數的方式
關于參數的默認值
算是老生常談了：函數的默認值只會在程序加載模塊并讀取到該函數的定義時設置一次
也就是說，如果給某參數賦予動態的值（
比如[]或者{}），則如果之后在調用函數的時候給參數賦予了其他參數，則以后再調用這個函數的時候，之前定義的默認值將會改變，成為上一次調用時賦予的值：
因此，更推薦使用None作為默認參數，在函數內進行判斷之后賦值：
類
__slots__
默認情況下，Python 用一個字典來保存一個對象的實例屬性。這使得我們可以在運行的時候動態的給類的實例添加新的屬性：
然而這個字典浪費了多余的空間 -— 很多時候我們不會創建那么多的屬性。因此通過__slots__可以告訴 Python
不要使用字典而是固定集合來分配空間。
__call__
通過定義類中的__call__方法，可以使該類的實例能夠像普通函數一樣調用。
通過這種方式實現的好處是，可以通過類的屬性來保存狀態，而不必創建一個閉包或者全局變量。
@classmethod & @staticmethod
@classmethod和@staticmethod很像，但他們的使用場景并不一樣。
類內部普通的方法，都是以
self作為第一個參數，代表著通過實例調用時，將實例的作用域傳入方法內；@classmethod以cls作為第一個參數，代表將類本身的作用域傳入。無論通過類來調用，還是通過類的實例調用，默認傳入的第一個參數都將是類本身@staticmethod不需要傳入默認參數，類似于一個普通的函數
來通過實例了解它們的使用場景：
假設我們需要創建一個名為Date的類，用于儲存 年/月/日 三個數據
上述代碼創建了Date類，該類會在初始化時設置day/month/year屬性，并且通過property設置了一個getter，可以在實例化之后，通過time獲取存儲的時間：
但如果我們想改變屬性傳入的方式呢？畢竟，在初始化時就要傳入年/月/日三個屬性還是很煩人的。能否找到一個方法，在不改變現有接口和方法的情況下，可以通過傳入2016-11-09這樣的字符串來創建一個Date實例？
你可能會想到這樣的方法：
但不夠好：
在類外額外多寫了一個方法，每次還得格式化以后獲取參數
這個方法也只跟
Date類有關沒有解決傳入參數過多的問題
此時就可以利用@classmethod，在類的內部新建一個格式化字符串，并返回類的實例的方法：
這樣，我們就可以通過Date類來調用from_string方法創建實例，并且不侵略、修改舊的實例化方式：
好處：
在
@classmethod內，可以通過cls參數，獲取到跟外部調用類時一樣的便利可以在其中進一步封裝該方法，提高復用性
更加符合面向對象的編程方式
而@staticmethod，因為其本身類似于普通的函數，所以可以把和這個類相關的 helper
方法作為@staticmethod，放在類里，然后直接通過類來調用這個方法。
將與日期相關的輔助類函數作為@staticmethod方法放在Date類內后，可以通過類來調用這些方法：
創建上下文管理器
上下文管理器，通俗的介紹就是：在代碼塊執行前，先進行準備工作；在代碼塊執行完成后，做收尾的處理工作。with語句常伴隨上下文管理器一起出現，經典場景有：
通過with語句，代碼完成了文件打開操作，并在調用結束，或者讀取發生異常時自動關閉文件，即完成了文件讀寫之后的處理工作。如果不通過上下文管理器的話，則會是這樣的代碼：
比較繁瑣吧？所以說使用上下文管理器的好處就是，通過調用我們預先設置好的回調，自動幫我們處理代碼塊開始執行和執行完畢時的工作。而通過自定義類的__enter__和__exit__方法，我們可以自定義一個上下文管理器。
然后可以以這樣的方式進行調用：
在調用的時候：
with語句先暫存了ReadFile類的__exit__方法然后調用
ReadFile類的__enter__方法__enter__方法打開文件，并將結果返回給with語句上一步的結果被傳遞給
file_read參數在
with語句內對file_read參數進行操作，讀取每一行讀取完成之后，
with語句調用之前暫存的__exit__方法__exit__方法關閉了文件
要注意的是，在__exit__方法內，我們關閉了文件，但最后返回True，所以錯誤不會被with語句拋出。否則with語句會拋出一個對應的錯誤。
點擊閱讀原文，查看更多 Python 教程和資源
閱讀原文：http://mp.weixin.qq.com/s?timestamp=1480391337&src=3&ver=1&signature=T3gIr*5RDc8Iyhss8lbLz5WT3HoUlzgk4lzSfqqH16Dr*uck1gLjvt5GVEaUQmqNraIG7Bva7zA53gfzMiGZsg13KaUR7oMoCIi7-HwqpjCKNDX6-RTscqkAAlWbSfLP-0zw-suLLKibR0aLSJTWWHChGxrSwXOkDtGfEF7aNH8=
