如何理解 Python 之禅：Explicit is better than implicit？

痛定思痛。 2022-09-14 03:14 182阅读 0赞

点击下方“逆锋起笔”，公众号回复 编程资源

领取大佬们推荐的学习资料
    
    剧照：刺杀小说家

作者：三点水

https://lotabout.me/2021/Explicit-is-Better-than-implicit

“Explicit is better than implicit” 是 The Zen of Python 中的一句格言。长久以来都觉得挺在理，直到有天有人用这句话为基础，提出了一个我不甚赞同的观点，才发现从来就没有真正理解过它。

神奇的是在搜索过程中，发现讨论这句格言的并没有多少，不同的讨论中对 "explicit" 含义的理解差别也很大，最终发现最好的讨论来自 Elixer 社区：On ‘Explicit is better than Implicit’ 。本文尝试列举见过的一些观点，以及自己的理解。

## Explicit 是什么含义？ ##

Explicit 这个单词释义为：

> stated clearly and in detail, leaving no room for confusion or doubt

“清楚详细地陈述，不容混淆或怀疑”。翻译成中文有“显式的”、“精密”、“不含糊”、“明确的”等多种翻译。在代码的语境下，什么样的代码才能称得上是 “explicit” 呢？网上看到了不同角度的观点。

## 一些观点 ##

### 把代码显式写出来 ###

显式地写出代码，也可以有多种理解方式，Making Games with Python and Pygame 中举了一个示例：

def getButtonClicked(x, y):
        if YELLOWRECT.collidepoint( (x, y) ):
            return YELLOW
        elif BLUERECT.collidepoint( (x, y) ):
            return BLUE
        elif REDRECT.collidepoint( (x, y) ):
            return RED
        elif GREENRECT.collidepoint( (x, y) ):
            return GREEN
        return None # 这里显式地返回了 None

书中提到最后一行显式写 `return None` 能让读者更直接理解代码的用途。

思考：这个样例容易理解，也很赞同，但是如何推而广之呢？Explicit 在上面的例子中体现在哪呢？

我理解它的重点在于，当所有的 `if` 语句都不命中时，默认的行为是未知的，而显示写出的 `return None` 则清楚地描述了默认的情形，即使 Python 的默认行为发生变化，该方法的行为也不会发生变化。

### 要具体、要特化 ###

这篇文章 明确表达了自己对“Explicit is Better than Implicit”的理解：

> Being explicit means being concrete and specific instead of abstract and general. It also means not to hide the behavior of a function.

Explicit 意味着要具体、特化，不要抽象、通用。同时不要隐藏函数的行为。

对于要具体、特化，文章中举例如下：

# Explicit                               |  # Implicit
    import requests                          |  from requests import *
    r = requests.get("https://lotabout.me")  |  r = get("https://lotabout.me")

对这个例子也是比较认同的。但我认为重点不在于 `requests.get` 怎么好，而在于 `import *` 不好。因为这样的话 `get` 方法的来源就不明确了，容易混淆，需要靠猜。相对的，下面的代码我认为也是好的：

from requests import get
    r = get("https://lotabout.me")

这里我的理解是，代码执行的逻辑，从溯源的角度上没有二义。如果用了 `import *`，同时两个模块中都有 `get` 方法，则容易混淆，不知道真正执行的是哪个方法。

### 不要隐藏函数行为 ###

同样来自上面提到的文章 ，示例如下：

#Explicit
    def read_csv(filename):
        # code for reading a csv
    
    def read_json(filename):
        # code for reading a json
    
    #Implicit
    def read(filename):
        # code for reading a csv or json
        # depending on the file extension

这个示例我不认同。从观念上，它与 OOP 中提到的封装的思想；从使用上，文件类型的判断的要求并没有消失，只是丢给用户自己实现了；进而从结果上，只要有多种文件类型存在，在某个层级上一定会有一个 `read` 方法的。

举例说，如果说不要隐藏函数的行为，那么我们在写 Web 服务的时候，在我们访问 DB 时，我们会希望直接处理 TCP 连接吗？Spring 框架选择隐藏这些行为，可以说是错误吗？

关键在于“预期”，与预期相符就是“Explicit”的，正如Elixer 社区的讨论 ：“Don’t surprise me”。于是 Explicit 的要求演变成如何给用户正确的预期？我的回答是：良好命名，遵循 common sense，除此之外需要教育。

### No Magic ###

Django 的 Design philosophies 中有如下描述：

> Magic shouldn’t happen unless there’s a really good reason for it. Magic is worth using only if it creates a huge convenience unattainable in other ways, and it isn’t implemented in a way that confuses developers who are trying to learn how to use the feature.

这里指的是不要用复杂的语言特性（大家常把元编程称作 Magic）。

这个观点的持保留意见，我认为重点还是在于知识、背景是否匹配。例如当我熟悉 Decorator 时，就会觉得用 decorator 来指定一个 REST API 的路由很直观，很容易理解。但对于不熟悉的人可能就完全不能理解数据的路径(data path)，不知道为什么一个注解是怎么真正完成 URL 到函数的绑定的。微信搜索公众号 逆锋起笔，关注后回复 编程资源，领取各种经典学习资料。

### 含义更直接 ###

还有一些讨论会指向同一段逻辑的不同写法，例如SO 上的讨论 举的例子：

a = []
    
    # ① my understanding is that this is implicit
    if not a:
       print("list is empty")
    
    # ② my understanding is that this is explicit
    if len(a) == 0:
       print("list is empty")

这是一个“矛盾”的讨论，题主认为 ② 是 explicit，下面的回答则指出写成 ① 的方式能应对更多的情形，如 `a` 不是列表的情形。我能理解 ① 的作用，但同时也赞同题主的观点，从阅读的角度来说 ② 是更直接的。

还有 Elixer 社区的讨论 ，例子一方面说明什么是语义上的“直接”，也间接反驳“不要隐藏函数行为”的观点：

if (person.sex === 1 and person.children.length > 0) { ...do something... }
    
    if (person.isFemale() and person.hasChildren()) { ...do something... }
    
    if (person.isFemaleParent()) { ...do something... }

从阅读代码的角度，明显上最后一种最容易阅读，更符合语言习惯，不容易有歧义。

## 我所理解的 Explicit ##

上面我们看到，“Explicit is Better than Implicit”这句话本身就是 implicit 的，有很多歧义的理解。

我自己的总结是：**Minimal Knowledge, No Surprise**。

对于阅读者/使用者而言，需要最少的知识去理解它，在我们隐藏复杂度的过程中，要保证函数/API/…行为符合预期，没有意外。

例如对于函数最后加上 `return None` 比不加要好，因为加上后，我们就不需要了解 Python 函数的默认返回值是什么。类似的，显式引用会更好：`from requests import get`，因为读者不需要去找 `get` 方法的来源，以及有重名时是哪个函数生效。

对于“不要隐藏函数行为”的做法，就有一定的反对意见。例如 `read_csv` 和 `read_json` 是否优于 `read` 方法？我认为此时 No Surprise 很重要。对于 csv, json 等文件格式我认为 `read` 更优，因为根据扩展名判断类型是一个共识，并不会有 surprise 发生。而如果读取的是 HDFS 上的文件，由于很多文件保存时并不会按扩展名保存，我认为此时 `read` 就容易有 Surprise，因此是不合适的。

对于 Magic，如果做法不是 common sense，则需要我们额外学习 Magic 的含义，就是属于"Implicit" 的，此时用来是不用，就要看它能给我们带来多大的好处了。同样的还有语言中的语法糖，经常需要额外学习知识才能看懂/自己使用。

最后对于“含义更直接”，认为在 No Surprise 的前提下，越接近“共识”越好，因为需要更少的知识。

## 小结 ##

关于 “Explicit is Better than Implicit?” 的理解，文章罗列了网上搜索的一些观点：

*  把代码显式写出来，如显式加上 `return None`
 *  要具体、要特化，如显式 import：`from requests import get`
 *  不要隐藏函数行为，如实现 `read_csv` 与 `read_json` 要好于只实现 `read`
 *  No Magic，如非必要，不要使用元编程
 *  含义更直接，如用 `len(a) == 0` 判断列表为空而不是 `not a`

最后总结并说明了自己对 “explicit” 含义的理解：**Minimal Knowledge, No Surprise**

当然，我们会发现 Minimal Knowledge 或者说“共识”对于不同的群体，在不同上下文之下是不同的。这也是我们需要经验去理解，需要花时间去沟通的内容了。

![9c747bc522bbd9fe26ffd5ff245dcee5.gif][]

**近期热门文章推荐：**

[Deepin 深度系统更新（2021.02.03）发布][Deepin _2021.02.03]  
[10 个“疯狂”的 Python 项目创意][10 _ Python]

[Python 下载的 11 种姿势，一种比一种高级！][Python _ 11]

[GitHub 上 25 个 Python 学习资源，墙裂推荐！][GitHub _ 25 _ Python]

感谢创作者的好文![61920cf1f0eb5479ad5ab03523c04e49.png][]

[9c747bc522bbd9fe26ffd5ff245dcee5.gif]: /images/20220828/f64528d1404c491f9091f3750ca8b493.png
[Deepin _2021.02.03]: http://mp.weixin.qq.com/s?__biz=MzUyMzM2ODUwMA==&mid=2247490789&idx=1&sn=1703a060fe342395810b9b524832a822&chksm=fa3cfdbecd4b74a8664d6b1cfd1239e53eef99161ffd9259cbd1bc4b7ae8b8777bf806e01ad4&scene=21#wechat_redirect
[10 _ Python]: http://mp.weixin.qq.com/s?__biz=MzUyMzM2ODUwMA==&mid=2247489763&idx=2&sn=e985956a39e2f14204189c9555640faf&chksm=fa3cf9b8cd4b70ae5c40967a81c187d78e54a99c550037c7c7e0ba55cf04e88c3971172465f8&scene=21#wechat_redirect
[Python _ 11]: http://mp.weixin.qq.com/s?__biz=MzUyMzM2ODUwMA==&mid=2247489804&idx=2&sn=43213b2b9f998f5d113c29a71897e1d7&chksm=fa3cf857cd4b7141cc49693b0b657b4ff1449482f9eb1a2ad79fad6fdee8c202f27dbac280b3&scene=21#wechat_redirect
[GitHub _ 25 _ Python]: http://mp.weixin.qq.com/s?__biz=MzUyMzM2ODUwMA==&mid=2247489601&idx=1&sn=2c421706f8182134419e9b5ea50fbd87&chksm=fa3cf91acd4b700c0aa8c73243098350c5409c70219d53bce4d1878085ac421b36b0a4f668d7&scene=21#wechat_redirect
[61920cf1f0eb5479ad5ab03523c04e49.png]: /images/20220828/f8a4e4c4b76e481b969fd1bd70865b10.png