当前位置：首页 > news >正文

解读《Effective Python 3rd Edition》：从练气到老魔

news 2026/6/1 6:37:18

Cloud_Shy 陪你解读《Effective Python 3rd Edition》：从练气到老魔

大家好呀，欢迎来到博主新开的《Effective Python 3rd Edition》学习笔记系列，毕竟也读过几百篇 SCI ，这次来试试阅读原版学习 Python 是一种怎样的体验。小伙伴们感兴趣的话，请一定要点赞，收藏加关注呀！

第一章 Pythonic Thinking

Python 程序员倾向于保持清晰明了，选择简单胜于复杂，并力求提高可读性。

Item 1: 清楚你正在使用的 Python 版本

贯穿本书的大部分代码是基于 Python 3.13 版本的（发布于 2024 年 10 月）。许多计算机操作系统都预装有多个版本的标准的 CPython 解释器。然而，在命令行中 Python 的默认含义可能并不清晰。 Python 通常被用作 Python 2.7 的别名，但有时它也可能被用作更旧版本（如 Python 2.6 或 Python 2.5）的别名。为了准确地找出你正在使用的 Python 版本，你可以使用--version。

C:\Users\SHY>python --version # 博主个人的 windows 命令行窗口中的安装的默认 Python 版本。 Python 3.11.5

若要使用其他 Python 运行环境（如 PyPy（https://www.pypy.org））来运行 Python 程序，则需使用它们各自特定的命令：

pypy3 --version

你还可以通过检查 sysbuilt-in 模块中的值来了解运行时使用的 Python 版本：

C:\Users\SHY>python Python 3.11.5 | packaged by Anaconda, Inc. | (main, Sep 11 2023, 13:26:23) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print(sys.platform) win32 >>> print(sys.implementation.name) cpython >>> print(sys.version_info) sys.version_info(major=3, minor=11, micro=5, releaselevel='final', serial=0) >>> print(sys.version) 3.11.5 | packaged by Anaconda, Inc. | (main, Sep 11 2023, 13:26:23) [MSC v.1916 64 bit (AMD64)]

长期以来，Python 核心开发人员和社区一直积极维护对 Python 2 和 Python 3 的支持。这两个版本在诸多方面存在显著差异，且存在互不兼容的问题，这加大了移植的难度。从版本 2 迁移至版本 3 是一个极其漫长且痛苦的过程，最终于 2020 年 4 月 20 日宣告结束，当时 Python 版本 2.7.18 正式发布。这是 Python 2 的最后一次正式发行。对于仍需为 Python 2 获取安全补丁和漏洞修复服务的人来说，剩下的唯一选择便是向商业软件供应商付费以获取支持，或者自行完成这些工作。

自那以后，Python 核心开发人员和社区一直专注于 Python 3 版本。核心语言的功能、标准库以及包与工具的生态系统都在不断得到改进。紧跟所有正在发生的变革与创新可能会让人感到应接不暇。了解最新情况的一个好方法就是阅读发行说明（https://docs.python.org/3/whatsnew/index.html），其中着重介绍了各版本的新增功能和变更内容。还有其他一些网站也会在您所依赖的社区包进行更新时向您发出通知（参见 Item 116: “了解如何查找社区构建的模块”）。

注意：

Python 3 是 Python 语言中最新且获得最广泛支持的版本，您应将其用于您的项目之中。
务必确认用于在您的系统上运行 Python 的命令行可执行文件版本与您所期望的一致。
Python 2 不再由核心开发者进行正式维护。

Item 2：遵循 PEP 8 风格指南

Python 增强提案 #8，也称为 PEP 8，是有关如何格式化 Python 代码的风格指南。您可以随意编写 Python 代码，只要它的语法有效。然而，采用一致的风格能使你的代码更易理解且更便于阅读。与更大范围内其他 Python 程序员共享一种共同的风格，有助于在项目上进行协作。但即便你是唯一会阅读你的代码的人，遵循风格指南也会使日后进行修改变得更为容易，并有助于你避免许多常见的错误。

PEP 8 就如何编写清晰易懂的 Python 代码提供了丰富的细节说明。随着 Python 语言的不断演进，这份文档也在不断更新。在线阅读完整的指南（https://www.python.org/dev/peps/pep-0008/）是非常值得的。以下是一些你务必遵循的规则。

1、空格

在 Python 中，空格具有语法上的重要性。Python 程序员尤其注重空格对代码清晰度的作用。请遵循以下与空格相关的指导原则：

用空格代替制表符进行缩排。
每个级别的语法上重要的缩进使用四个空格。
行的长度不应超过 79 个字符。
长表达式到附加行的延续应比其正常缩进级别缩进四个额外空格。
在文件中，函数和类应该用两个空行分隔。
在一个类中，方法之间应该用一个空行分隔。
在字典中，每个键和冒号之间不要有空格；如果对应的值位于同一行，则在其前面添加一个空格。
在变量赋值中，在 = 运算符之前和之后放置一个且仅一个空格。
对于类型注释，请确保变量名和冒号之间没有分隔，并在类型信息之前使用空格。

2、命名

PEP 8 建议为语言中的不同部分采用独特的命名方式。这些约定使得在阅读代码时很容易区分每个名称对应的类型。请遵循以下与命名相关的准则：

函数、变量和属性应采用小写下划线格式。
受保护的实例属性应采用_leading_下划线格式。
私有实例属性应采用__double_leading__双下划线格式。
类（包括例外）应采用大写的 Word 格式。
模块级常量应采用 ALL_CAP 格式（全部使用大写字母书写单词）。
类中的实例方法应该使用 self（引用对象）作为第一个参数的名称。
类方法应使用 cls（引用类）作为第一个参数的名称。

3、表达式和陈述

Python 之禅指出：“应该有一种（最好只有一种）明显的方法来做到这一点。” PEP 8 试图将这种风格编入其表达和陈述的指南中：

使用内联否定（if a is not b）而不是正表达式的否定（if not a is b）。
不要通过将长度与零进行比较（如果 len(somelist) == 0）来检查空容器或序列（如 [] 或 " "）。使用 if not somelist 并假设空值将隐式计算为 False。对于非空容器或序列（如 [1] 或“hi”）也是如此。对于非空值，if somelist 的语句隐式为 True。
避免使用单行 if 语句、for 和 while 循环以及 except 复合语句。为了清晰起见，将它们分散在多行中。
如果一行无法容纳表达式，请用括号将其括起来，并添加换行符和缩进以使其更易于阅读。
优先使用括号包围多行表达式，而不是使用 \ 换行符来延续字符。

4、Imports

PEP 8 建议了一些关于如何导入模块并在代码中使用它们的指南：

始终将导入语句（包括 from x import y）放在文件的顶部。
导入模块时始终使用模块的绝对名称，而不是相对于当前模块自己的路径的名称。例如，要从 barpackage 中导入 foomodule，您应该使用 from bar import foo，而不仅仅是 import foo。
如果必须执行相对导入，请使用 from 的显式语法。导入 foo。
导入应按以下顺序分节：标准库模块、第三方模块、您自己的模块。每个小节都应按字母顺序导入。

5、自动化

如果到目前为止你读到的内容似乎需要记住很多，有个好消息是：Python 社区正在围绕一个用于自动 PEP 8 格式化的通用工具进行合并：它被称为 black (https://github.com/psf/black)，它是一个官方的 Python 软件基金会项目。 black 提供的配置选项非常少，这使得使用同一代码库的开发人员很容易就代码风格达成一致。安装和使用 black 非常简单：

C:\Users\SHY>pip install black C:\Users\SHY>echo 'def hello_word(): return "Hello, World!"' > example.py C:\Users\SHY>python -m black example.py reformatted example.py All done! ✨ 🍰 ✨ 1 file reformatted.

除了 black 之外，还有许多其他社区工具可以帮助您自动改进源代码。许多 IDE 和编辑器都包含样式检查工具、自动格式化程序和类似的插件。一种流行的代码分析器是 pylint (https://github.com/pylint-dev/pylint)；它有助于执行 PEP 8 风格指南并检测 Python 程序中许多其他类型的常见错误（有关更多示例，请参阅 Item 3：“永远不要期望 Python 在编译时检测错误”）。

注意：

编写 Python 代码时，请始终遵循 Python 增强提案 #8 (PEP 8) 风格指南。
与更大的 Python 社区共享共同的风格可以促进与其他人的协作。
使用一致的风格可以更轻松地稍后修改自己的代码。
black 和 pylint 等社区工具可以自动遵守 PEP8，从而轻松保持源代码良好的风格。

Item 3：永远不要指望 Python 在编译时检测错误

当加载 Python 程序并准备执行时，源代码被解析为抽象语法树并检查明显的结构错误。例如，构造不良的 if 语句将引发语法错误异常，指示代码有什么问题：
if True# 语法错误 print(‘hello’)

Traceback ... SyntaxError: expected ':'

值文字中的错误也将被及早检测到并引发异常：

不幸的是，这就是您在执行之前可以从 Python 获得的所有保护。除了基本标记化错误和解析错误之外的任何内容都不会被标记为问题。

由于 Python 的高度动态特性，即使是看起来有明显错误的简单函数，在程序执行之前也不会被报告为有问题。例如，这里我定义了一个函数，其中 my_var 变量在传递给 print 之前显然没有被赋值：

def bad_reference(): print(my_var) my_var =123

但这在函数执行之前不会引发异常：

C:\Users\SHY>python Python 3.11.5 | packaged by Anaconda, Inc. | (main, Sep 11 2023, 13:26:23) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def bad_reference(): ... print(my_var) ... my_var =123 >>> >>> bad_reference() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in bad_reference UnboundLocalError: cannot access local variable 'my_var' where it is not associated with a value

这不被视为静态错误的原因是，Python 程序动态分配局部和全局变量是有效的。例如，这里我定义了一个函数，该函数是否有效取决于输入参数：

def sometimes_ok(x): if x: my_var =123 print(my_var)

此调用运行良好：

>>> def sometimes_ok(x): ... if x: ... my_var =123 ... print(my_var) ... >>> sometimes_ok(True) 123

下面这个会导致运行时异常：

Python 也不会预先捕获数学错误。看起来这在程序执行之前显然是一个错误：

def bad_math(): return 1/0

但除法运算符的含义可能会根据所涉及的值而变化，因此类似这样的错误检查也会推迟到运行时：

>>> def bad_math(): ... return 1/0 ... >>> bad_math() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in bad_math ZeroDivisionError: division by zero

Python 也不会静态检测未定义方法、提供的参数过多或过少、返回类型不匹配以及许多其他看似明显的问题。有一些社区工具可以帮助您在执行之前检测其中一些错误，例如 flake8linter (https://github.com/PyCQA/flake8) 和与打字内置模块一起使用的类型检查器（请参阅 Item 124：“通过打字考虑静态分析以消除错误”）。

最终，在编写惯用的 Python 时，您将在运行时遇到大多数错误。 Python 语言优先考虑运行时灵活性而不是编译时错误检测。因此，重要的是在运行时检查您的假设是否正确（请参阅 Item 81：“断言内部假设并提出未达到的期望”），并通过自动化测试验证代码的正确性（请参阅 Item 109：“优先使用集成测试而不是单元测试”）。

注意：