对Python之禅的解释
由 Al Sweigart 发布
Tim Peters 所著的 Python之禅 是20条关于 Python 语言设计的指导。你的 Python 代码不必要一定遵循这些指导，但是记在心里对你是有用的。Python之禅是一个彩蛋，或者是隐藏的笑话，当你运行 import this，它便会出现。
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!注：奇怪的是，只有19条准则被写下来了。据报道，吉多·范·罗斯姆（Guido van Rosum）说，失踪的第20句格言是“一些古怪的提姆·彼得斯（Tim Peters）在开玩笑。”
最后，这些指导方针是可以支持或反对的意见。就像所有好的道德准则一样，它们有时会自相矛盾以提供最大的灵活性。以下是我对这些格言的解释：
1.Beautiful is better than ugly.
美丽胜于丑陋。
程序员经常快速编写代码，而不考虑可读性。虽然代码不一定是可读的，但Python语言本身的代码必须经过深思熟虑，保持一致，并且使用起来也是一种乐趣。当然，不是每个脚本都需要漂亮，漂亮是主观的，但是Python的流行很大程度上是因为它很容易使用。
2.Explicit is better than implicit.
显式优于隐式。
“这句格言是不言自明的”，这将是对任何格言的糟糕解释。同样，代码最好是详细和明确的。您应该避免将代码的功能隐藏在模糊的语言特性后面，而这些特性需要熟悉才能完全理解。
3.4.Simple is better than complex. Complex is better than complicated.
简单胜于复杂。复杂胜于凌乱。
这两句格言提醒我们，任何事情都可以用简单或复杂的技术来完成。对于一个简单的问题，比如建造一个鸟舍，一个简单的解决方案是更好的。另一方面，建造柴油火车发动机是一个复杂的问题，需要复杂的技术。即使你可以用鸟巢技术制造柴油火车引擎，你可能最终会得到一个复杂的，Rube Goldberg鲁布·戈德堡机械 的鸟巢零件安排，这不是一个理想的解决方案。喜欢简单而不是复杂，但要知道简单的局限性。
5.Flat is better than nested.
扁平的比嵌套的好。
程序员喜欢将事物组织成类别，尤其是包含子类别的类别，而这些子类别包含其它子子类别。这些层次结构通常不会增加组织，因为它们会增加官僚作风。只在一个顶层模块或类中使用代码，而不是跨多个子模块或子类拆分代码是可以的。如果您制作的包和模块需要像 import spam.eggs.bacon.ham.foo.bar 这样的代码，那么您的代码就太复杂了。
6.Sparse is better than dense.
稀疏胜于稠密。
程序员通常喜欢将尽可能多的功能塞进尽可能少的代码中，例如下面的一行：print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))。虽然这样的代码可能会给他们的朋友留下深刻的印象，但它会激怒那些不得不去理解它的同事。分散在多行上的代码通常比密集的一行程序更容易读取。
7.Readability counts.
可读性很重要。
虽然 strcmp() 可能显然意味着自20世纪70年代以来一直在用C编程的人的“字符串比较”功能，但现代计算机有足够的内存来写出完整的函数名。不要从你的名字中去掉元音，或写下过于简洁的代码。代码的读取频率比它的写入频率高，所以显式的、可读的代码比简洁的、无文档的代码更重要。
8.9.Special cases aren't special enough to break the rules. Although practicality beats purity.
特殊情况不足以打破规则。尽管实用性胜过纯洁性。
这两句成串的格言互相矛盾。编程中充满了程序员在代码中应该努力实现的“最佳实践”。绕开这些做法进行快速黑客攻击可能很诱人，但可能导致大量不一致、不可读的代码。然而，向后弯曲以遵守规则可能导致高度抽象、不可读的代码。Java编程语言试图将所有代码与面向对象的范例相匹配，通常会导致大量的样板代码，即使是最小的程序。通过经验，在这两个格言之间走线路变得更容易。随着时间的推移，你不仅要学习规则，还会学习何时打破规则。
10.11.Errors should never pass silently.Unless explicitly silenced.
错误不应该默默地传递，除非是明确沉默传递。
程序员经常忽略错误消息并不意味着程序应该停止发出错误消息。当函数返回错误代码或 None 而不是引发异常时，可能会发生无提示错误。这两句格言告诉我们，程序快速失败并崩溃，总比默默错误并继续运行程序好。稍后不可避免地会发生的错误将更难调试，因为它们与原始原因相差甚远。尽管你总是可以选择明确地忽略你的程序导致的错误，但是要确保你有意识地选择这样做。
12.In the face of ambiguity, refuse the temptation to guess.
面对模棱两可，拒绝猜测的诱惑。
计算机使人类变得迷信：为了驱除我们计算机中的恶魔，我们执行神圣的仪式，将它们关闭，然后再打开。据说这可以解决任何神秘的问题。然而，计算机并不是魔法。如果你的代码不起作用，那就只有一个原因，只有仔细的、批判性的思考才能解决它。拒绝盲目尝试解决方案的诱惑，直到某件事似乎奏效；通常你只是掩盖了问题，而不是解决了它。
13.There should be one-- and preferably only one --obvious way to do it.
应该有一种而且最好只有一种显而易见的方法来做到这一点。
这与 Perl 编程语言的座右铭“有不止一种方法可以做到这一点”相悖。“事实证明，有三种或四种不同的代码编写方法来完成相同的工作，这是一把双刃剑：您在编写代码方面具有灵活性，但现在您必须学习所有可能的方法来编写代码以便阅读。这种灵活性不值得学习编程语言所需的3或4倍的努力。
14.Although that way may not be obvious at first unless you're Dutch.
不过，除非你是荷兰人，这种方式一开始可能并不明显。
这句话是个笑话。Python的创造者和（BDFL-Benevolent Dictator for Life）仁慈的终身独裁者Guido Van Rossum是荷兰人。然而，即使这句格言也不能阻止Python合并三种不同的字符串格式。
15.16.Now is better than never. Although never is often better than *right* now.
做也许好过不做，但不假思索就动手还不如不做。
这两句格言告诉我们，挂起或陷入无限循环的代码明显比没有挂起或陷入无限循环的代码更糟糕。然而，几乎可以肯定的是，等待程序完成比让它以错误的结果过早完成要好。
17.18.If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.
如果实现很难解释，那是个坏主意。如果实现很容易解释，这可能是一个好主意。
python努力使程序员的工作更简单，而不是适应计算机，因此程序运行更快。程序不仅要被编写它的程序员理解，还要被维护代码的其他程序员理解。这两句格言提醒我们，如果“高性能”代码如此复杂以至于程序员无法理解和调试，那么它就是糟糕的代码。但遗憾的是，仅仅因为向别人解释程序的代码很容易，并不意味着它不是坏代码。编程很难。
19.Namespaces are one honking great idea -- let's do more of those!
名称空间是一个很好的主意，让我们做更多的事情吧！
命名空间（以及全局和局部作用域）是防止一个模块或作用域中的名称与另一个模块或作用域中的名称冲突的关键。但也要记住，扁平比嵌套好：尽管名称空间很好，但只应创建名称空间以防止命名冲突，而不应添加不必要的分类。
像所有关于编程的观点一样，我在这里写的那些观点可以被反驳，或者可能与你的情况无关。关于如何编写代码的争论很少像您认为的那样富有成效。（除非你写了一整本充满编程观点的书。）
转载：https://inventwithpython.com/blog/2018/08/17/the-zen-of-python-explained/
作者：Al Sweigart
其它解释：
Python之禅 by Tim Peters
优美胜于丑陋（Python 以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）
当存在多种可能，不要尝试去猜测，而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的 Dutch是指 Guido ）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）
转《【Python】基础知识—Python之禅》https://blog.csdn.net/weixin_41767438/article/details/80452859
原《《Python之禅》的翻译和解释》 https://blog.csdn.net/qq_38721302/article/details/82947568
转《《Python之禅》的翻译和解释》https://blog.csdn.net/Blateyang/article/details/79394175