[Python] Python 編程藝術

• ref= http://www.slideshare.net/wilhelmshen/py-art

• 1. Python 編程藝術享受高效無誤且充滿樂趣的編程
• 2. def hello(): print hello world!
• 3. 什麼樣的函數返回 None？
• 4. 沒有訊息就是最好的訊息
• 5. 對許多有經驗的程式員來說True / 1 並不是執行成功的意思
• 6. None 是最好的沉默 雖然 0 也不錯，然而在 Python 中預設的傳回值是 None
• 7. 函數不能既返回結果 又返回錯誤
• 8. 瘮人的設計“如果 open() 返回 errno”try: fileobj = open(filename)# 雖然 open 能返回錯誤，但不能保證所有都捕獲了啊# 所以還是 catch 下比較保險？except: raise # 暫且 raise 吧，鬼知道會是什麼狀況if isinstance(fileobj, file): # 正確返回 file 對象 ... 正常的工作代 碼 ...elif isinstance(fileobj,
  int): # 返回錯誤碼，執行錯誤處理 errno = fileobj raise IOError(errno, os.strerror(errno))# 還會有其他狀況？# 既然已經有多種傳回型別了，指不定還會不會節外生枝# 這回還真無法預期了else: raise IOError(-1, Unknown error)
• 9. 其實 C 語言是一樣一樣的因為 C 沒有異常機制，而認為這種在 Python 中 return 一切 的做法，顯然是源於 C 語言的“優良作風” —— 這是一種誤解，其實 C 處理異常結果的思路 和 Python 是完全一樣的
• 10. Python 的標準介面try: fobj = open(filename)except IOError: ... 檔案開啟失敗 ...... 只要沒有異常，fobj 就一定是 file 對象 ...try: data = fobj.read()except IOError: ... 讀取失敗 ...... 只要沒有異常，data 就一定是 str  類型 ...
• 11. 最小驚訝原則
• 12. 誤區 1函數傳回值的可預見性，並不完全意 味著僅返回一種傳回值
• 13. 誤區 2 函數盡量返回一種傳回值並不意味著返回同一種“類型” 或基於同一種“基類”的資料
• 14. 一個例子，雖然返回的都是 Tupleif ... : return username, passwdelse: return name, age, gender
• 15. Duck Typing
• 16. 檔案系統檔案：open(...) 與 file(...) 可以是任何介質，磁碟/記憶體檔案/音效卡/NFS/FUSE 等位元組流檔案：StringIO(...)通訊端檔案：socket.makefile(...)管道：os.popen(...) 函數族 popen() 、popen2()、popen3() 、popen4()標準輸入輸出： sys.stdin 、sys.stdout 、sys.stderr其他：gzip.open(..)
  等
• 17. 沒有所謂基類（BaseFile） 卻行為一致
• 18. 將靜態語言編程思想套用於動態語言 是非常危險的
• 19. 動態語言不需要預分配記憶體 危險的初始化
• 20. 也沒有所謂虛表拋出 NotImplementedError 就安全了？
• 21. 避免把問題演變成邏輯錯誤
• 22. 解譯器錯誤比運行期錯誤好 力圖把錯誤提早到程式跑起來之前
• 23. 程式崩潰比邏輯錯誤好力圖把可能存在的邏輯錯誤變成崩潰
• 24. 尤其不要捕獲 AttributeError 發現邏輯問題的最好機會
• 25. 拋出 AttributeError 和 KeyError而不是通過返回 None 來錯失機會
• 26. 瞭解各種 Python 異常的含義 盡量使用現有異常類型 Python 預設了豐富的異常類型 很多情況下設計額外的異常會和現有異常類型重合 發生混淆、影響系統穩定和增加維護成本
• 27. OSError & IOErrorerrno 在 Python 中的傳播
• 28. 壞訊息是 IOError 並不是一種 OSError好訊息是 socket.error 可以用 IOError 擷取
• 29. 先 TypeError 而後 ValueError int(None) / int(hello)
• 30. 當你開始大量 raiseTypeError 和 ValueError 你就要注意了
• 31. raise 是用來補刀的
• 32. AssertError合情合理的邏輯錯誤？
• 33. 使用 assert 的場合
• 34. 異常策略總結 不要做輸入檢測 不要編防寫保護性代碼 不要容錯，使程式崩潰 不要處理異常，盡量製造和拋出異常
• 35. 一個脆弱的程式？我們都知道沒有完美的程式，出錯在所難免，任何一個小異常都能讓整個程式崩潰，對於一個已經開始運營的軟體產品 —— 這是可以接受的嗎？
• 36. 單點複雜度
• 37. 讓專業的程式去做專業的事
• 38. SIMPLE IS BETTER
• 39. 推論 1檢查只會讓輸入變得更不可靠
• 40. 推論 2越多的安全性原則只會讓程式 變得更不安全
• 41. 只有當錯誤不是錯誤哪些異常是就地解決的？
• 42. 同樣的寫法不同的命運如何編寫快速的 dict 檢索邏輯
• 43. Python 異常的效能之迷 快卻沒有想象中那麼快 慢卻沒有想象中那麼慢
• 44. 回到 Duck-Typing 這個主題
• 45. 嚴重誤區Duck-Typing 是基於對象和 對象方法的嗎？
• 46. 如果把 for ... in obj 替換成 obj.__iter__()
• 47. Duck-Typing 是基於調用協議的 a, b = ab
• 48. 基於函數名和參數名的 調用協議
• 49. 調用者（CPython、PyPy）
• 50. 避免使用可修改對象作為 函數的預設參數
• 51. 顯式總比隱藏好login(username=xxx, password=***)
• 52. 暴露但不濫用盡量消除私人和隱藏屬性 儘可能暴露所有介面
• 53. 不使用 __slots__在所有層次上做到開放、透明
• 54. 重複代碼未必是壞事 放棄一部分封裝讓使用者明確知道自己在做什麼
• 55. 哪些情況是不需要封裝的？
• 56. 效能殺手Python 的函數調用是重量級的
• 57. 厚膠合層橫向複雜度與縱向複雜度
• 58. 不要使用 super()當用到 super() 時程式就已經失敗了
• 59. Python / Unix 第一定律 程式複雜度只和行數相關
• 60. 謝謝觀賞沈崴於上海 Python 聚會（五分鐘） 2010 年 5 月 30 日
• 61. Python 編程藝術 凡事並無絕對 運用存乎一心