[[380419]]

本文是 Python 之禪特殊系列的一部分，重點是第十二、十三和十四原則：模糊性和明確性的作用。

最小驚喜原則是設計用戶界面時的一個 準則。它是說，當用戶執行某項操作時，程序執行的事情應該使用戶盡量少地感到意外。這和孩子們喜歡一遍又一遍地讀同一本書的原因是一樣的：沒有什么比能夠預測并讓預測成真更讓人欣慰的了。

在開發 ABC 語言（Python 的靈感來源）的過程中，一個重要的見解是，編程設計是用戶界面，需要使用與 UI 設計者相同的工具來設計。值得慶幸的是，從那以后，越來越多的語言采用了 UI 設計中的可承受性affordance和人體工程學ergonomics的概念，即使它們的應用并不嚴格。

這就引出了 Python 之禪 中的三個原則。

面對歧義，要拒絕猜測的誘惑In the face of ambiguity, refuse the temptation to guess

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 使程序更具可預測性。

盡量找一種，最好是唯一一種明顯的解決方案There should be one—and preferably only one—obvious way to do it

預測也會出現偏差。給定一個任務，你能預知要實現該任務的代碼嗎？當然，不可能完美地預測。畢竟，編程是一項具有創造性的任務。

但是，不必有意提供多種冗余方式來實現同一目標。從某種意義上說，某些解決方案或許 “更好” 或 “更 Python 化Pythonic”。

對 Python 美學欣賞部分是因為，可以就哪種解決方案更好進行健康的辯論。甚至可以持不同觀點而繼續編程。甚至為使其達成一致，接受不同意的觀點也是可以的。但在這一切之下，必須有一種這樣的認識，即正確的解決方案終將會出現。我們必須希望，通過商定實現目標的最佳方法，而最終達成真正的一致。

雖然這種方式一開始可能并不明顯（除非你是荷蘭人）Although that way may not be obvious at first (unless you're Dutch)

這是一個重要的警告：首先，實現任務的最佳方法往往不明顯。觀念在不斷發展。Python 也在進化。逐塊讀取文件的最好方法，可能要等到 Python 3.8 時使用 walrus 運算符（:=）。

逐塊讀取文件這樣常見的任務，在 Python 存在近 30年 的歷史中并沒有 “唯一的最佳方法”。

當我在 1998 年從 Python 1.5.2 開始使用 Python 時，沒有一種逐行讀取文件的最佳方法。多年來，知道字典中是否有某個鍵的最佳方法是使用關鍵字 .haskey，直到 in 操作符出現才發生改變。

只是要意識到找到實現目標的一種（也是唯一一種）方法可能需要 30 年的時間來嘗試其它方法，Python 才可以不斷尋找這些方法。這種歷史觀認為，為了做一件事用上 30 年是可以接受的，但對于美國這個存在僅 200 多年的國家來說，人們常常會感到不習慣。

從 Python 之禪的這一部分來看，荷蘭人，無論是 Python 的創造者 Guido van Rossum 還是著名的計算機科學家 Edsger W. Dijkstra，他們的世界觀是不同的。要理解這一部分，某種程度的歐洲人對時間的感受是必不可少的。