Add #16
This commit is contained in:
parent
5368a68f4f
commit
27e41ddd72
422
README.md
422
README.md
|
@ -19,9 +19,8 @@
|
|||
|
||||
『Python 工匠』这个系列文章,是我的一次小小尝试。它专注于分享 Python 编程中的一些偏 **『小』** 的东西。希望能够帮到每一位编程路上的匠人。
|
||||
|
||||
|
||||
## 文章列表
|
||||
|
||||
|
||||
- 1\. <del>善用变量改善代码质量</del> [[图书版:变量与注释](https://www.zlovezl.cn/book/ch01_variables.html)]
|
||||
- [2. 编写条件分支代码的技巧](zh_CN/2-if-else-block-secrets.md)
|
||||
- [3. 使用数字与字符串的技巧](zh_CN/3-tips-on-numbers-and-strings.md)
|
||||
|
@ -37,6 +36,7 @@
|
|||
- [13. 写好面向对象代码的原则(中)](zh_CN/13-write-solid-python-codes-part-2.md)
|
||||
- [14. 写好面向对象代码的原则(下)](zh_CN/14-write-solid-python-codes-part-3.md)
|
||||
- [15. 在边界处思考](zh_CN/15-thinking-in-edge-cases.md)
|
||||
- [16. 语句、表达式和海象操作符](zh_CN/16-stmt-expr-and-walrus-operator.md)
|
||||
|
||||
如果你觉得读 GitHub 文件不太方便,也可以访问[这个镜像站点](https://pengzhangzhi.github.io/one-python-craftsman/)阅读所有文章(由 [@pengzhangzhi](https://github.com/pengzhangzhi) 搭建)。
|
||||
|
||||
|
@ -50,251 +50,261 @@
|
|||
|
||||
### 1. [善用变量改善代码质量](zh_CN/1-using-variables-well.md)
|
||||
|
||||
* 如何为变量起名
|
||||
* 1 - 变量名要有描述性,不能太宽泛
|
||||
* 2 - 变量名最好让人能猜出类型
|
||||
* 『什么样的名字会被当成 bool 类型?』
|
||||
* 『什么样的名字会被当成 int/float 类型?』
|
||||
* 其他类型
|
||||
* 3 - 适当使用『匈牙利命名法』
|
||||
* 4 - 变量名尽量短,但是绝对不要太短
|
||||
* 使用短名字的例外情况
|
||||
* 5 - 其他注意事项
|
||||
* 更好的使用变量
|
||||
* 1 - 保持一致性
|
||||
* 2 - 尽量不要用 globals()/locals()
|
||||
* 3 - 变量定义尽量靠近使用
|
||||
* 4 - 合理使用 namedtuple/dict 来让函数返回多个值
|
||||
* 5 - 控制单个函数内的变量数量
|
||||
* 6 - 及时删掉那些没用的变量
|
||||
* 7 - 能不定义变量就不定义
|
||||
* 结语
|
||||
- 如何为变量起名
|
||||
- 1 - 变量名要有描述性,不能太宽泛
|
||||
- 2 - 变量名最好让人能猜出类型
|
||||
- 『什么样的名字会被当成 bool 类型?』
|
||||
- 『什么样的名字会被当成 int/float 类型?』
|
||||
- 其他类型
|
||||
- 3 - 适当使用『匈牙利命名法』
|
||||
- 4 - 变量名尽量短,但是绝对不要太短
|
||||
- 使用短名字的例外情况
|
||||
- 5 - 其他注意事项
|
||||
- 更好的使用变量
|
||||
- 1 - 保持一致性
|
||||
- 2 - 尽量不要用 globals()/locals()
|
||||
- 3 - 变量定义尽量靠近使用
|
||||
- 4 - 合理使用 namedtuple/dict 来让函数返回多个值
|
||||
- 5 - 控制单个函数内的变量数量
|
||||
- 6 - 及时删掉那些没用的变量
|
||||
- 7 - 能不定义变量就不定义
|
||||
- 结语
|
||||
|
||||
### 2. [编写条件分支代码的技巧](zh_CN/2-if-else-block-secrets.md)
|
||||
|
||||
* 最佳实践
|
||||
* 1 - 避免多层分支嵌套
|
||||
* 2 - 封装那些过于复杂的逻辑判断
|
||||
* 3 - 留意不同分支下的重复代码
|
||||
* 4 - 谨慎使用三元表达式
|
||||
* 常见技巧
|
||||
* 1 - 使用“德摩根定律”
|
||||
* 2 - 自定义对象的“布尔真假”
|
||||
* 3 - 在条件判断中使用 all() / any()
|
||||
* 4 - 使用 try/while/for 中 else 分支
|
||||
* 常见陷阱
|
||||
* 1 - 与 None 值的比较
|
||||
* 2 - 留意 and 和 or 的运算优先级
|
||||
* 结语
|
||||
* 注解
|
||||
- 最佳实践
|
||||
- 1 - 避免多层分支嵌套
|
||||
- 2 - 封装那些过于复杂的逻辑判断
|
||||
- 3 - 留意不同分支下的重复代码
|
||||
- 4 - 谨慎使用三元表达式
|
||||
- 常见技巧
|
||||
- 1 - 使用“德摩根定律”
|
||||
- 2 - 自定义对象的“布尔真假”
|
||||
- 3 - 在条件判断中使用 all() / any()
|
||||
- 4 - 使用 try/while/for 中 else 分支
|
||||
- 常见陷阱
|
||||
- 1 - 与 None 值的比较
|
||||
- 2 - 留意 and 和 or 的运算优先级
|
||||
- 结语
|
||||
- 注解
|
||||
|
||||
### 3. [使用数字与字符串的技巧](zh_CN/3-tips-on-numbers-and-strings.md)
|
||||
|
||||
* 最佳实践
|
||||
* 1 - 少写数字字面量
|
||||
* 使用 enum 枚举类型改善代码
|
||||
* 2 - 别在裸字符串处理上走太远
|
||||
* 3 - 不必预计算字面量表达式
|
||||
* 实用技巧
|
||||
* 1 - 布尔值其实也是“数字”
|
||||
* 2 - 改善超长字符串的可读性
|
||||
* 当多级缩进里出现多行字符串时
|
||||
* 3 - 别忘了那些 “r” 开头的内建字符串函数
|
||||
* 4 - 使用“无穷大” float("inf")
|
||||
* 常见误区
|
||||
* 1 - “value += 1” 并非线程安全
|
||||
* 2 - 字符串拼接并不慢
|
||||
* 结语
|
||||
- 最佳实践
|
||||
- 1 - 少写数字字面量
|
||||
- 使用 enum 枚举类型改善代码
|
||||
- 2 - 别在裸字符串处理上走太远
|
||||
- 3 - 不必预计算字面量表达式
|
||||
- 实用技巧
|
||||
- 1 - 布尔值其实也是“数字”
|
||||
- 2 - 改善超长字符串的可读性
|
||||
- 当多级缩进里出现多行字符串时
|
||||
- 3 - 别忘了那些 “r” 开头的内建字符串函数
|
||||
- 4 - 使用“无穷大” float("inf")
|
||||
- 常见误区
|
||||
- 1 - “value += 1” 并非线程安全
|
||||
- 2 - 字符串拼接并不慢
|
||||
- 结语
|
||||
|
||||
### 4. [容器的门道](zh_CN/4-mastering-container-types.md)
|
||||
|
||||
* 底层看容器
|
||||
* 写更快的代码
|
||||
* 1 - 避免频繁扩充列表/创建新列表
|
||||
* 2 - 在列表头部操作多的场景使用 deque 模块
|
||||
* 3 - 使用集合/字典来判断成员是否存在
|
||||
* 高层看容器
|
||||
* 写扩展性更好的代码
|
||||
* 面向容器接口编程
|
||||
* 常用技巧
|
||||
* 1 - 使用元组改善分支代码
|
||||
* 2 - 在更多地方使用动态解包
|
||||
* 3 - 使用 next() 函数
|
||||
* 4 - 使用有序字典来去重
|
||||
* 常见误区
|
||||
* 1 - 当心那些已经枯竭的迭代器
|
||||
* 2 - 别在循环体内修改被迭代对象
|
||||
* 总结
|
||||
* 系列其他文章
|
||||
* 注解
|
||||
- 底层看容器
|
||||
- 写更快的代码
|
||||
- 1 - 避免频繁扩充列表/创建新列表
|
||||
- 2 - 在列表头部操作多的场景使用 deque 模块
|
||||
- 3 - 使用集合/字典来判断成员是否存在
|
||||
- 高层看容器
|
||||
- 写扩展性更好的代码
|
||||
- 面向容器接口编程
|
||||
- 常用技巧
|
||||
- 1 - 使用元组改善分支代码
|
||||
- 2 - 在更多地方使用动态解包
|
||||
- 3 - 使用 next() 函数
|
||||
- 4 - 使用有序字典来去重
|
||||
- 常见误区
|
||||
- 1 - 当心那些已经枯竭的迭代器
|
||||
- 2 - 别在循环体内修改被迭代对象
|
||||
- 总结
|
||||
- 系列其他文章
|
||||
- 注解
|
||||
|
||||
### 5. [让函数返回结果的技巧](zh_CN/5-function-returning-tips.md)
|
||||
|
||||
* 编程建议
|
||||
* 1 - 单个函数不要返回多种类型
|
||||
* 2 - 使用 partial 构造新函数
|
||||
* 3 - 抛出异常,而不是返回结果与错误
|
||||
* 4 - 谨慎使用 None 返回值
|
||||
* 1 - 作为操作类函数的默认返回值
|
||||
* 2 - 作为某些“意料之中”的可能没有的值
|
||||
* 3 - 作为调用失败时代表“错误结果”的值
|
||||
* 5 - 合理使用“空对象模式”
|
||||
* 6 - 使用生成器函数代替返回列表
|
||||
* 7 - 限制递归的使用
|
||||
* 总结
|
||||
* 附录
|
||||
- 编程建议
|
||||
- 1 - 单个函数不要返回多种类型
|
||||
- 2 - 使用 partial 构造新函数
|
||||
- 3 - 抛出异常,而不是返回结果与错误
|
||||
- 4 - 谨慎使用 None 返回值
|
||||
- 1 - 作为操作类函数的默认返回值
|
||||
- 2 - 作为某些“意料之中”的可能没有的值
|
||||
- 3 - 作为调用失败时代表“错误结果”的值
|
||||
- 5 - 合理使用“空对象模式”
|
||||
- 6 - 使用生成器函数代替返回列表
|
||||
- 7 - 限制递归的使用
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 6. [异常处理的三个好习惯](zh_CN/6-three-rituals-of-exceptions-handling.md)
|
||||
|
||||
* 前言
|
||||
* 三个好习惯
|
||||
* 1 - 只做最精确的异常捕获
|
||||
* 2 - 别让异常破坏抽象一致性
|
||||
* 3 - 异常处理不应该喧宾夺主
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- 三个好习惯
|
||||
- 1 - 只做最精确的异常捕获
|
||||
- 2 - 别让异常破坏抽象一致性
|
||||
- 3 - 异常处理不应该喧宾夺主
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 7. [编写地道循环的两个建议](zh_CN/7-two-tips-on-loop-writing.md)
|
||||
|
||||
* 前言
|
||||
* 什么是“地道”的循环?
|
||||
* enumerate() 所代表的编程思路
|
||||
* 建议1:使用函数修饰被迭代对象来优化循环
|
||||
* 1 - 使用 product 扁平化多层嵌套循环
|
||||
* 2 - 使用 islice 实现循环内隔行处理
|
||||
* 3 - 使用 takewhile 替代 break 语句
|
||||
* 4 - 使用生成器编写自己的修饰函数
|
||||
* 建议2:按职责拆解循环体内复杂代码块
|
||||
* 复杂循环体如何应对新需求
|
||||
* 使用生成器函数解耦循环体
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- 什么是“地道”的循环?
|
||||
- enumerate() 所代表的编程思路
|
||||
- 建议1:使用函数修饰被迭代对象来优化循环
|
||||
- 1 - 使用 product 扁平化多层嵌套循环
|
||||
- 2 - 使用 islice 实现循环内隔行处理
|
||||
- 3 - 使用 takewhile 替代 break 语句
|
||||
- 4 - 使用生成器编写自己的修饰函数
|
||||
- 建议2:按职责拆解循环体内复杂代码块
|
||||
- 复杂循环体如何应对新需求
|
||||
- 使用生成器函数解耦循环体
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 8. [使用装饰器的技巧](zh_CN/8-tips-on-decorators.md)
|
||||
|
||||
* 前言
|
||||
* 最佳实践
|
||||
* 1 - 尝试用类来实现装饰器
|
||||
* 2 - 使用 wrapt 模块编写更扁平的装饰器
|
||||
* 常见错误
|
||||
* 1 - “装饰器”并不是“装饰器模式”
|
||||
* 2 - 记得用 functools.wraps() 装饰内层函数
|
||||
* 3 - 修改外层变量时记得使用 nonlocal
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- 最佳实践
|
||||
- 1 - 尝试用类来实现装饰器
|
||||
- 2 - 使用 wrapt 模块编写更扁平的装饰器
|
||||
- 常见错误
|
||||
- 1 - “装饰器”并不是“装饰器模式”
|
||||
- 2 - 记得用 functools.wraps() 装饰内层函数
|
||||
- 3 - 修改外层变量时记得使用 nonlocal
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 9. [一个关于模块的小故事](zh_CN/9-a-story-on-cyclic-imports.md)
|
||||
|
||||
* 前言
|
||||
* 一个关于模块的小故事
|
||||
* 需求变更
|
||||
* 解决环形依赖问题
|
||||
* 小 C 的疑问
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- 一个关于模块的小故事
|
||||
- 需求变更
|
||||
- 解决环形依赖问题
|
||||
- 小 C 的疑问
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 10. [做一个精通规则的玩家](zh_CN/10-a-good-player-know-the-rules.md)
|
||||
|
||||
* 前言
|
||||
* Python 里的规则
|
||||
* 案例:从两份旅游数据中获取人员名单
|
||||
* 第一次蛮力尝试
|
||||
* 尝试使用集合优化函数
|
||||
* 对问题的重新思考
|
||||
* 利用集合的游戏规则
|
||||
* 使用 dataclass 简化代码
|
||||
* 案例总结
|
||||
* 其他规则如何影响我们
|
||||
* 使用 `__format__` 做对象字符串格式化
|
||||
* 使用 `__getitem__` 定义对象切片操作
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- Python 里的规则
|
||||
- 案例:从两份旅游数据中获取人员名单
|
||||
- 第一次蛮力尝试
|
||||
- 尝试使用集合优化函数
|
||||
- 对问题的重新思考
|
||||
- 利用集合的游戏规则
|
||||
- 使用 dataclass 简化代码
|
||||
- 案例总结
|
||||
- 其他规则如何影响我们
|
||||
- 使用 `__format__` 做对象字符串格式化
|
||||
- 使用 `__getitem__` 定义对象切片操作
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 11. [高效操作文件的三个建议](zh_CN/11-three-tips-on-writing-file-related-codes.md)
|
||||
|
||||
* 前言
|
||||
* 建议一:使用 pathlib 模块
|
||||
* 使用 pathlib 模块改写代码
|
||||
* 其他用法
|
||||
* 建议二:掌握如何流式读取大文件
|
||||
* 标准做法的缺点
|
||||
* 使用 read 方法分块读取
|
||||
* 利用生成器解耦代码
|
||||
* 建议三:设计接受文件对象的函数
|
||||
* 如何编写兼容二者的函数
|
||||
* 总结
|
||||
* 附录
|
||||
* 注解
|
||||
- 前言
|
||||
- 建议一:使用 pathlib 模块
|
||||
- 使用 pathlib 模块改写代码
|
||||
- 其他用法
|
||||
- 建议二:掌握如何流式读取大文件
|
||||
- 标准做法的缺点
|
||||
- 使用 read 方法分块读取
|
||||
- 利用生成器解耦代码
|
||||
- 建议三:设计接受文件对象的函数
|
||||
- 如何编写兼容二者的函数
|
||||
- 总结
|
||||
- 附录
|
||||
- 注解
|
||||
|
||||
### 12. [写好面向对象代码的原则(上)](zh_CN/12-write-solid-python-codes-part-1.md)
|
||||
|
||||
* 前言
|
||||
* Python 对 OOP 的支持
|
||||
* SOLID 设计原则
|
||||
* SOLID 原则与 Python
|
||||
* S:单一职责原则
|
||||
* 违反“单一职责原则”的坏处
|
||||
* 拆分大类为多个小类
|
||||
* 另一种方案:使用函数
|
||||
* O:开放-关闭原则
|
||||
* 如何违反“开放-关闭原则”
|
||||
* 使用类继承来改造代码
|
||||
* 使用组合与依赖注入来改造代码
|
||||
* 使用数据驱动思想来改造代码
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- Python 对 OOP 的支持
|
||||
- SOLID 设计原则
|
||||
- SOLID 原则与 Python
|
||||
- S:单一职责原则
|
||||
- 违反“单一职责原则”的坏处
|
||||
- 拆分大类为多个小类
|
||||
- 另一种方案:使用函数
|
||||
- O:开放-关闭原则
|
||||
- 如何违反“开放-关闭原则”
|
||||
- 使用类继承来改造代码
|
||||
- 使用组合与依赖注入来改造代码
|
||||
- 使用数据驱动思想来改造代码
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 13. [写好面向对象代码的原则(中)](zh_CN/13-write-solid-python-codes-part-2.md)
|
||||
|
||||
* 前言
|
||||
* 里氏替换原则与继承
|
||||
* L:里氏替换原则
|
||||
* 一个违反 L 原则的样例
|
||||
* 不当继承关系如何违反 L 原则
|
||||
* 一个简单但错误的解决办法
|
||||
* 正确的修改办法
|
||||
* 另一种违反方式:子类修改方法返回值法返回值)
|
||||
* 分析类方法返回结果
|
||||
* 如何修改代码
|
||||
* 方法参数与 L 原则
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- 里氏替换原则与继承
|
||||
- L:里氏替换原则
|
||||
- 一个违反 L 原则的样例
|
||||
- 不当继承关系如何违反 L 原则
|
||||
- 一个简单但错误的解决办法
|
||||
- 正确的修改办法
|
||||
- 另一种违反方式:子类修改方法返回值法返回值)
|
||||
- 分析类方法返回结果
|
||||
- 如何修改代码
|
||||
- 方法参数与 L 原则
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 14. [写好面向对象代码的原则(下)](zh_CN/14-write-solid-python-codes-part-3.md)
|
||||
|
||||
* 前言
|
||||
* D:依赖倒置原则
|
||||
* 需求:按域名分组统计 HN 新闻数量
|
||||
* 为 SiteSourceGrouper 编写单元测试
|
||||
* 使用 mock 模块
|
||||
* 实现依赖倒置原则
|
||||
* 依赖倒置后的单元测试
|
||||
* 问题:一定要使用抽象类 abc 吗?
|
||||
* 问题:抽象一定是好东西吗?
|
||||
* I:接口隔离原则
|
||||
* 例子:开发页面归档功能
|
||||
* 问题:实体类不符合 HNWebPage 接口规范
|
||||
* 成功违反 I 协议
|
||||
* 如何分拆接口
|
||||
* 一些不容易发现的违反情况
|
||||
* 现实世界中的接口隔离
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- D:依赖倒置原则
|
||||
- 需求:按域名分组统计 HN 新闻数量
|
||||
- 为 SiteSourceGrouper 编写单元测试
|
||||
- 使用 mock 模块
|
||||
- 实现依赖倒置原则
|
||||
- 依赖倒置后的单元测试
|
||||
- 问题:一定要使用抽象类 abc 吗?
|
||||
- 问题:抽象一定是好东西吗?
|
||||
- I:接口隔离原则
|
||||
- 例子:开发页面归档功能
|
||||
- 问题:实体类不符合 HNWebPage 接口规范
|
||||
- 成功违反 I 协议
|
||||
- 如何分拆接口
|
||||
- 一些不容易发现的违反情况
|
||||
- 现实世界中的接口隔离
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 15. [在边界处思考](zh_CN/15-thinking-in-edge-cases.md)
|
||||
|
||||
* 前言
|
||||
* 第一课:使用分支还是异常?
|
||||
* 获取原谅比许可简单(EAFP)
|
||||
* 当容器内容不存在时
|
||||
* 使用 defaultdict 改写示例
|
||||
* 使用 setdefault 取值并修改
|
||||
* 使用 dict.pop 删除不存在的键
|
||||
* 当列表切片越界时
|
||||
* 好用又危险的 “or” 操作符
|
||||
* 不要手动去做数据校验
|
||||
* 不要忘记做数学计算
|
||||
* 总结
|
||||
* 附录
|
||||
- 前言
|
||||
- 第一课:使用分支还是异常?
|
||||
- 获取原谅比许可简单(EAFP)
|
||||
- 当容器内容不存在时
|
||||
- 使用 defaultdict 改写示例
|
||||
- 使用 setdefault 取值并修改
|
||||
- 使用 dict.pop 删除不存在的键
|
||||
- 当列表切片越界时
|
||||
- 好用又危险的 “or” 操作符
|
||||
- 不要手动去做数据校验
|
||||
- 不要忘记做数学计算
|
||||
- 总结
|
||||
- 附录
|
||||
|
||||
### 16. [语句、表达式和海象操作符](zh_CN/16-stmt-expr-and-walrus-operator.md)
|
||||
|
||||
- [表达式的特点
|
||||
- [海象操作符
|
||||
- 1. 用于分支语句
|
||||
- 2. 消除推导式中的重复
|
||||
- 3. 捕获推导式的中间结果
|
||||
- 4. 赋值表达式的限制
|
||||
- 其他建议
|
||||
- 1. “更紧凑”不等于“更好”
|
||||
- 2. 宜少不宜多
|
||||
|
|
|
@ -0,0 +1,307 @@
|
|||
让我们从两行最简单的 Python 代码开始。
|
||||
|
||||
```python
|
||||
>>> name = 'piglei'
|
||||
>>> print(f'Hello {name}!')
|
||||
Hello piglei!
|
||||
```
|
||||
|
||||
这是一个“Hello World”程序,你也许已经见过它无数次,对里面的每个字母都了如指掌。但你可能从未意识到,上面两行代码,刚好对应着 Python 语言里的两个重要概念:**语句(statement)** 和 **表达式(expression)**。
|
||||
|
||||
具体来说,`name = 'piglei'` 是一行赋值语句,它将字符串 `'piglei'` 赋给了 `name` 变量。`print(f'Hello {name}!')` 则是一个表达式,它通过调用内置函数 `print` 往屏幕打印信息。
|
||||
|
||||
### 表达式的特点
|
||||
|
||||
编写代码时,语句和表达式是两类最基本的代码单元。
|
||||
|
||||
虽然在日常表达中,我们会把语句和表达式区分开来,但二者并非完全不同——表达式实际上就是一种特殊的语句。和普通语句比起来,表达式的特别之处在于它拥有一个(或多个)返回值。
|
||||
|
||||
举例来说,前面的 `print(...)` 表达式就会返回一个值:`None`。你可以像下面这样获取它:
|
||||
|
||||
```python
|
||||
# print 函数总是返回 None
|
||||
>>> val = print(f'Hello {name}!')
|
||||
Hello piglei!
|
||||
>>> val is None
|
||||
True
|
||||
```
|
||||
|
||||
虽然这么做没啥实际用途,但它足够体现出表达式的独特之处——因为你永远无法对普通语句做出类似的事情。无论是“赋值语句”、“循环语句”,还是一个“条件分支语句”,你永远都无法将其赋值给某个变量,这在语法上无从谈起:
|
||||
|
||||
```python
|
||||
>>> val = (name = 'piglei')
|
||||
File "<stdin>", line 1
|
||||
val = (name = 'piglei')
|
||||
^
|
||||
SyntaxError: invalid syntax #1
|
||||
```
|
||||
|
||||
1. 意料之中,抛出了语法错误(`SyntaxError`)
|
||||
|
||||
不过,Python 3.8 版本发布以后,表达式和语句间的分界线突然变得前所未有的模糊。上面这行错误代码,只要增加一个冒号就可以变得合法:
|
||||
|
||||
```python
|
||||
>>> val = (name := 'piglei')
|
||||
>>> val, name
|
||||
('piglei', 'piglei')
|
||||
```
|
||||
|
||||
这便是“海象操作符(walrus operator)”——`:=`——的威力。
|
||||
|
||||
### 海象操作符
|
||||
|
||||
也许你会好奇,“海象操作符”这名字是怎么来的,为啥蟒蛇(python)的世界里会突然冒出一头海象(walrus)?假如你把头向左倾斜 90 度,仔细观察 `:=` 符号,就会发现其中的奥秘:它看起来就像一头海象的面部,冒号是鼻孔,等号是它的两根长牙。
|
||||
|
||||
使用 `:=` 操作符,可以构建出学名为“赋值表达式(Assignment Expressions)”的东西。在赋值表达式出现前,变量的赋值只能通过语句来完成。它出现后,我们便可在一个表达式内完成赋值,同时返回所赋值的变量。
|
||||
|
||||
```python
|
||||
>>> val = (name := 'piglei') #1
|
||||
```
|
||||
|
||||
1. `(name := 'piglei')` 就是一个赋值表达式,它同时做到了两件事:将 `'piglei'` 赋值为 `name` 变量;返回 `name` 变量的值。
|
||||
|
||||
赋值表达式几乎可以被用在任何你能想到的地方,比如条件分支、循环和列表推导式,等等。
|
||||
|
||||
让我们来看几个典型场景。
|
||||
|
||||
#### 1. 用于分支语句
|
||||
|
||||
有一个函数,功能是从一段字符串中找出第一个以字母“w”开头的单词,如未找到,再尝试找以“w”结尾的。代码可以这么写:
|
||||
|
||||
```python
|
||||
import re
|
||||
|
||||
LEADING_W_WORD = re.compile(r'\bw\w*?\b', re.I)
|
||||
TRAILING_W_WORD = re.compile(r'\b\w*?w\b', re.I)
|
||||
|
||||
def find_w_word(s):
|
||||
"""找到并打印字符串中第一个以 w 开头的单词,如未找到,再试着找 w 结尾的"""
|
||||
if LEADING_W_WORD.search(s):
|
||||
word = LEADING_W_WORD.search(s).group()
|
||||
print(f'Found word starts with "w": {word}')
|
||||
elif TRAILING_W_WORD.search(s):
|
||||
word = TRAILING_W_WORD.search(s).group()
|
||||
print(f'Found word ends with "w": {word}')
|
||||
```
|
||||
|
||||
调用效果如下:
|
||||
|
||||
```python
|
||||
>>> find_w_word('Guido found several examples where a programmer repeated a subexpression')
|
||||
Found word starts with "w": where
|
||||
```
|
||||
|
||||
上面的代码存在一个小问题,每个负责正则搜索的表达式 `LEADING_W_WORD.search(s)` 分别重复出现了两次:一次在分支判断处,另一次在分支内部。
|
||||
|
||||
这种重复会让代码更难维护,也会影响程序的执行性能。因此,大部分时候我们会通过定义变量来消除重复:
|
||||
|
||||
```python
|
||||
def find_w_word_v2(s):
|
||||
"""找到并打印字符串中第一个以 w 开头的单词,如未找到,再试着找 w 结尾的"""
|
||||
l_match = LEADING_W_WORD.search(s) #1
|
||||
if l_match:
|
||||
word = l_match.group()
|
||||
print(f'Found word starts with "w": {word}')
|
||||
else:
|
||||
t_match = TRAILING_W_WORD.search(s)
|
||||
if t_match:
|
||||
word = t_match.group()
|
||||
print(f'Found word ends with "w": {word}')
|
||||
```
|
||||
|
||||
1. 定义一个变量 `l_match` 保存 `.search()` 返回的匹配结果
|
||||
|
||||
但这样虽然消除了重复,却引入了更深的嵌套层级,还是难以让人满意。
|
||||
|
||||
有了赋值表达式后,我们可以更进一步,直接在分支判断语句中一次性完成表达式的运算和赋值。于是,代码可以被进一步简化成这样:
|
||||
|
||||
```python
|
||||
def find_w_word_v3(s):
|
||||
"""找到并打印字符串中第一个以 w 开头的单词,如未找到,再试着找 w 结尾的"""
|
||||
if l_match := LEADING_W_WORD.search(s):
|
||||
word = l_match.group()
|
||||
print(f'Found word starts with "w": {word}')
|
||||
elif t_match := TRAILING_W_WORD.search(s):
|
||||
word = t_match.group()
|
||||
print(f'Found word ends with "w": {word}')
|
||||
```
|
||||
|
||||
修改之后,代码变得更扁平,逻辑也更加紧凑了。
|
||||
|
||||
除了 `if` 条件分支,`while` 循环中也可以使用赋值表达式。比如,下面这种模式的循环代码十分常见:
|
||||
|
||||
```python
|
||||
while True:
|
||||
chunk = fp.read(2048)
|
||||
if not chunk:
|
||||
break
|
||||
# 继续后续对 chunk 的处理...
|
||||
```
|
||||
|
||||
如果使用赋值表达式,它可以被简化成下面这样:
|
||||
|
||||
```python
|
||||
while chunk := fp.read(2048):
|
||||
# 继续后续对 chunk 的处理...
|
||||
```
|
||||
|
||||
#### 2. 消除推导式中的重复
|
||||
|
||||
前面演示了在分支语句中使用赋值表达式,除此之外,你也可以在各类推导式中使用它。
|
||||
|
||||
举个例子,在构建一个推导式时,我们有时可能会需要同时做到以下两件事:
|
||||
|
||||
1. 预计算每个成员,判断结果是否满足要求
|
||||
2. 如满足,将预计算的结果置入新对象
|
||||
|
||||
下面的代码完成了这个功能:
|
||||
|
||||
```python
|
||||
# 仅挑选 func(...) > 100 的成员构建新列表
|
||||
new_objs = [func(p) for p in objs if func(p) > 100]
|
||||
```
|
||||
|
||||
虽然它满足需求,但也有一个严重的问题:`func(p)` 在每次迭代时会被重复执行两次,这很可能会成为一个潜在的性能隐患。
|
||||
|
||||
在以前,如果你想优化这个问题,除了把表达式拆成普通 `for` 循环外没什么其他办法。但有了赋值表达式,代码可被轻松优化成这样:
|
||||
|
||||
```python
|
||||
new_objs = [v for p in objs if (v := func(p)) > 100]
|
||||
```
|
||||
|
||||
重复的函数调用原地消失了。
|
||||
|
||||
#### 3. 捕获推导式的中间结果
|
||||
|
||||
从某种角度上看,赋值表达式是一种有“副作用”的表达式,它的副作用就是在返回值的同时,完成变量赋值。如果你有意地利用这种副作用,就能完成一些相当出人意料的事情。
|
||||
|
||||
让我来举个例子。`any()` 是 Python 的一个内建函数,它接收一个可迭代对象作为参数,在遍历该对象的过程中,如果发现任何布尔值为真的成员,函数就立刻返回 `True`,否则返回 `False`。
|
||||
|
||||
一个常见的使用场景如下所示:
|
||||
|
||||
```python
|
||||
def has_lucky_number(nums):
|
||||
"""判断给定的列表中,是否存在能被 7 整除的数字"""
|
||||
return any(n % 7 == 0 for n in nums)
|
||||
```
|
||||
|
||||
调用示例:
|
||||
|
||||
```python
|
||||
>>> has_lucky_number([4, 8, 9])
|
||||
False
|
||||
>>> has_lucky_number([4, 8, 21, 9])
|
||||
True
|
||||
```
|
||||
|
||||
某日,需求变更了。函数不仅需要知道是否存在被 7 整除的数字,还得把这个数字找出来。代码该怎么改?`any(...)` 像是肯定没法再用了,不如写一个平平无奇的 `for` 循环吧。
|
||||
|
||||
但其实,如果你使用赋值表达式搭配上 `any` 函数的短路执行特性,下面这几行代码也可以达成使命:
|
||||
|
||||
```python
|
||||
def get_lucky_number(nums):
|
||||
"""返回列表中能被 7 整除的数字,如没有则返回 None"""
|
||||
if any((ret := n) % 7 == 0 for n in nums):
|
||||
return ret
|
||||
return None
|
||||
```
|
||||
|
||||
调用示例:
|
||||
|
||||
```python
|
||||
>>> get_lucky_number([4, 8, 9])
|
||||
>>> get_lucky_number([4, 8, 21, 9])
|
||||
21
|
||||
```
|
||||
|
||||
和之前相比,新代码最主要的修改在于将 `n` 替换成了 `(ret := n)`——一个有副作用的赋值表达式。在 `any` 函数进行循环遍历 `nums` 列表的过程中,当前被迭代的成员 `n` 会被赋到 `ret` 变量上,如其刚好满足条件,就会直接被当做结果返回。
|
||||
|
||||
借助赋值表达式的副作用,我们成功捕获了第一个满足条件的成员,只用一行代码就实现了需求。
|
||||
|
||||
#### 4. 赋值表达式的限制
|
||||
|
||||
从外观上看,赋值表达式和赋值语句极为相似,仅多了一个冒号 `:`。但如果你继续深入,会发现它其实被施加了许多普通赋值语句所没有的限制。
|
||||
|
||||
比如,它在作为整句独立使用时,两边必须添加括号:
|
||||
|
||||
```
|
||||
>>> x := 1
|
||||
SyntaxError: invalid syntax
|
||||
>>> (x := 1)
|
||||
1
|
||||
```
|
||||
|
||||
此外,赋值表达式也无法直接操作对象属性(或字典的键):
|
||||
|
||||
```python
|
||||
# 普通赋值语句
|
||||
>>> s.foo = 'bar'
|
||||
>>> d['foo'] = 'bar'
|
||||
|
||||
# 赋值表达式无法做到
|
||||
>>> (s.foo := 'bar')
|
||||
SyntaxError: cannot use assignment expressions with attribute
|
||||
>>> (d['foo'] := 'bar')
|
||||
SyntaxError: cannot use assignment expressions with subscript
|
||||
```
|
||||
|
||||
诸如此类的限制,是语言设计者为避免人们滥用赋值表达式而为之。但即便有着这些限制,赋值表达式这个 Python 3.8 中增加的新语法,已然为人们在 Python 中“遣词造句”,带来了巨大的可能性和想象空间。
|
||||
|
||||
> 如果你想了解更多关于”赋值表达式“的细节,建议阅读官方 PEP: [PEP 572 – Assignment Expressions](https://peps.python.org/pep-0572/)。
|
||||
|
||||
### 其他建议
|
||||
|
||||
下面是关于”赋值表达式“的两个使用建议。
|
||||
|
||||
#### 1. “更紧凑”不等于“更好”
|
||||
|
||||
正如前面所展示的,我们可以像玩积木一样组合使用赋值表达式,写出更精炼、更紧凑的代码。但对于代码而言,“更紧凑”不能和“更好”画上等号。关于这点,我很喜欢 Tim Peters 举过的[一个简单例子](https://peps.python.org/pep-0572/#appendix-a-tim-peters-s-findings)。
|
||||
|
||||
Tim Peters 说自己不喜欢“匆匆忙忙”的代码,讨厌将概念上无关的逻辑写到同一行代码里。比方说,与其像下面这样写:
|
||||
|
||||
```python
|
||||
i = j = count = nerrors = 0
|
||||
```
|
||||
|
||||
他更倾向于改成这样:
|
||||
|
||||
```python
|
||||
i = j = 0
|
||||
count = 0
|
||||
nerrors = 0
|
||||
```
|
||||
|
||||
第一种写法虽然紧凑,但其实忽视了一件重要的事:这几个变量分属 3 类不同用途(分别是循环索引值、个数和错误数量),它们只是碰巧都为 `0` 而已。将代码拆成 3 行以后,虽没那么紧凑,但概念上实际变得更清晰了。
|
||||
|
||||
在使用赋值表达式时,我们尤其需要避免掉进盲目追求“精炼”和“紧凑”的陷阱里,多多关注每行代码在逻辑上的联系,而不要整日盯着**字面意义上**的精简。
|
||||
|
||||
#### 2. 宜少不宜多
|
||||
|
||||
赋值表达式是 Python 3.8 引入的新特性,已经发布 3 年有余。但就自身感受而言,除了在一些 Python 教程文章中,我在其他项目里极少见到它的身影。
|
||||
|
||||
人们很少使用赋值表达式,我猜主要出于两方面的原因。
|
||||
|
||||
其一,Python 3.8 仍是一个相对较新的版本,许多项目尚未完成版本升级。其二,赋值表达式本身非常灵活,适用场景非常多,使用起来难以把控尺度,因此许多开发者对其抱着较为警惕的态度。再加上它本身也不提供任何普通语句做不到的独特功能——不是雪中送炭,只是锦上添花——因此大家不愿尝鲜。
|
||||
|
||||
上面的第一类原因,随着时间的推移会慢慢得到解决。我们主要看第二类。
|
||||
|
||||
我认为,大部分开发者的担忧确实有一定道理,赋值表达式在将代码变得紧凑的同时,也带来了更高的理解成本和上手门槛。而且平心而论,一些用了赋值表达式的代码,真的会给我一种“*这么写是不是过于聪明了?*”的感觉。
|
||||
|
||||
拿之前的这段代码为例:
|
||||
|
||||
```python
|
||||
if any((ret := n) % 7 == 0 for n in nums):
|
||||
return ret
|
||||
```
|
||||
|
||||
如果是一个私人脚本,也许我会愿意把代码写成上面那样。但在多人参与的真实项目里,我目前可能更愿意用一段平平无奇的 `for` 循环替代它。很多时候,相比“聪明”的代码,“笨”代码才是我们更需要的东西,它们能为项目的参与者省去许多沟通和维护上的成本。
|
||||
|
||||
总体而言,关于是否应该在项目中使用赋值表达式,我的建议是:
|
||||
|
||||
- 在分支语句的消除重复场景,使用赋值表达式
|
||||
- 在推导式的消除重复场景,使用赋值表达式
|
||||
- 其他情况下,优先使用普通赋值语句,哪怕这意味着更多代码和少量重复(比如“获取第一个满足条件的成员”场景)
|
||||
|
||||
希望以上的内容对你有所帮助。
|
||||
|
||||
> 这篇文章属于“Python 工匠”系列,如果你喜欢它,也欢迎了解我的书[《Python工匠:案例、技巧与工程实践》\[试读\]](https://www.zlovezl.cn/book/index.html) | [\[书评\]](https://book.douban.com/subject/35723705/),其中有大量同样风格的 Python 编程进阶知识。
|
Loading…
Reference in New Issue