Python 编程艺术 - Presentation Transcript

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 编程艺术 凡事并无绝对 运用存乎一心