最小惊讶原则是 用户界面设计中的一个指导原则。它指出，当用户执行一个操作时，程序应该做最不会让用户感到惊讶的事情。这与孩子们一遍又一遍地喜欢读同一本书的原因相同：对人们来说，没有什么比能够预测并让这些预测成真更令人安慰的了。
在 ABC 语言（Python 的灵感来源）的开发过程中，一个重要的见解是，编程语言是用户界面，需要使用 UI 设计师使用的相同工具进行设计。值得庆幸的是，从那时起，更多的语言采用了来自 UI 设计的示能性和人体工程学概念，即使它们的应用不太严格。
这将我们带到 Python 之禅 中的接下来的三个原则。
面对歧义，拒绝猜测的诱惑。
1 + "1" 的结果应该是什么？"11" 和 2 都是有效的猜测。这个表达式是模糊的：它没有一个单一的行为方式不会让至少一部分人感到惊讶。
一些语言选择猜测。在 JavaScript 中，结果是 "11"。在 Perl 中，结果是 2。在 C 中，自然地，结果是空字符串。面对歧义，JavaScript、Perl 和 C 都进行了猜测。
在 Python 中，这会引发 TypeError：一个非静默错误。捕获 TypeError 是非典型的：它通常会终止程序或至少是当前任务（例如，在大多数 Web 框架中，它将终止当前请求的处理）。
Python 拒绝猜测 1 + "1" 的含义。程序员被迫编写意图明确的代码：可以是 1 + int("1")，结果为 2；也可以是 str(1) + "1"，结果为 "11"；或者 "1"[1:]，结果为空字符串。通过拒绝猜测，Python 使程序更具可预测性。
应该有一种——最好只有一种——显而易见的方法来做到这一点。
预测也朝着另一个方向发展。给定一个任务，你能预测出为实现它而编写的代码吗？当然，完美预测是不可能的。毕竟，编程是一项创造性的任务。
然而，没有理由故意提供多种冗余的方式来实现同一件事。在某种意义上，有些解决方案“更好”或“更 Pythonic”。
对 Pythonic 美学的欣赏部分在于，可以就哪个解决方案更好进行健康的辩论。甚至可以不同意并继续编程。甚至可以为了和谐而同意保留分歧。但在这背后，必须有一种感觉，最终，正确的解决方案将会出现。必须有希望，最终我们可以通过就实现目标的最佳方式达成一致，生活在真正的和谐之中。
尽管这种方式起初可能并不明显（除非你是荷兰人）。
这是一个重要的警告：通常不明显的是，起初，实现任务的最佳方式是什么。想法在不断发展。Python 也在不断发展。以块为单位读取文件的最佳方式，可能是等到 Python 3.8 并使用 海象运算符。
这个常见的任务，以块为单位读取文件，在 Python 存在的近 30 年 里，并没有“单一最佳方法”。
当我 1998 年开始使用 Python 1.5.2 时，并没有单一最佳方法来逐行读取文件。多年来，了解字典是否具有键的最佳方法是使用 .haskey，直到 in 运算符成为最佳方法。
只有认识到有时，找到实现目标的唯一（且唯一）方法可能需要 30 年的尝试替代方案，Python 才能继续致力于找到这些方法。这种历史观，即 30 年对于某件事来说是可以接受的时间，对于美国人来说常常感到陌生，因为这个国家只存在了 200 多年。
荷兰人，无论是 Python 的创建者 Guido van Rossum 还是著名的计算机科学家 Edsger W. Dijkstra，根据 Python 之禅的这一部分，他们有不同的世界观。对时间的某种欧洲式欣赏对于理解它是必不可少的。
1 条评论