Python之禅，解释
Tim Peters 的 Python 之禅是 Python 语言设计的 20 条指南。 您的 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 开的一些离奇的笑话”。
最后，这些指导方针是可以支持或反对的意见。 就像所有好的道德准则一样，它们有时会自相矛盾以提供最大的灵活性。 以下是我自己对这些格言的解释：
美丽总比丑陋好。
程序员经常快速编写代码而不关心可读性。 虽然代码不一定是可读的，但 Python 语言本身的代码必须经过深思熟虑、保持一致并且使用起来很愉快。 当然，并不是每个脚本都需要美观，而且美观是主观的，但 Python 的流行很大程度上是因为它易于使用。
显式优于隐式。
“这句格言是不言自明的”，这对任何格言来说都是一个糟糕的解释。 同样，代码最好是冗长和明确的。 您应该避免将代码的功能隐藏在需要熟悉才能完全理解的晦涩语言功能之后。
简单胜于复杂。 复杂总比复杂好。
这两个格言提醒我们，构建任何东西都可以使用简单或复杂的技术来完成。 对于一个简单的问题，比如建造一个鸟舍，一个简单的解决方案更好。 另一方面，制造柴油火车发动机是一个复杂的问题，需要复杂的技术。 即使您可以在技术上使用鸟舍技术制造柴油火车发动机，您最终也可能会得到一个复杂的 Rube Goldberg 鸟舍部件布置，这不是理想的解决方案。 喜欢简单胜过复杂，但知道简单的局限性。
扁平比嵌套好。
程序员喜欢将事物组织成类别，尤其是包含子类别的类别，子类别又包含其他子类别。 这些等级制度通常不会增加组织，而是增加官僚作风。 将代码放在一个顶层模块或类中而不是分散在多个子模块或子类中是可以的。 如果您制作需要代码的包和模块 import spam.eggs.bacon.ham.foo.bar，那么你的代码就太复杂了。
稀疏比密集好。
程序员通常喜欢将尽可能多的功能塞进尽可能少的代码中，例如像下面这样的一行代码： print('n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it’ll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.
可读性很重要。
尽管 strcmp() 对于自 1970 年代以来一直使用 C 编程的人来说，这显然意味着“字符串比较”函数，现代计算机有足够的内存来写出完整的函数名称。 不要去掉名字中的元音字母或编写过于简洁的代码。 阅读代码的次数多于编写代码的次数，因此明确的、可读的代码比简洁的、未记录的代码更重要。
特殊情况不足以违反规则。 虽然实用胜过纯粹。
这两个格言作为一组出现，相互矛盾。 编程充满了程序员应该在他们的代码中努力实现的“最佳实践”。 绕过这些实践以进行快速破解可能很诱人，但可能会导致出现不一致、不可读的代码。 然而，竭力遵守规则可能会导致代码高度抽象、难以阅读。 Java 编程语言试图使所有代码都符合其面向对象的范例，这通常会导致即使是最小的程序也会产生大量样板代码。 随着经验的积累，在这两个格言之间划清界线会变得更容易。 随着时间的推移，您不仅会了解规则，还会知道何时打破规则。
错误不应该悄无声息地过去。 除非明确沉默。
仅仅因为程序员经常忽略错误消息并不意味着程序应该停止发出它们。 当函数返回错误代码或 None 而不是引发异常。 这两句格言告诉我们，程序最好是 fail fast 和崩溃而不是消除错误并继续运行程序。 以后不可避免地发生的错误将更难调试，因为它们与最初的原因相去甚远。 尽管您始终可以选择明确忽略您的程序导致的错误，但请确保您是有意识地选择这样做。
面对模棱两可的情况，拒绝猜测的诱惑。
计算机让人类变得迷信：为了驱除我们计算机中的恶魔，我们执行了将它们关闭然后再打开的神圣仪式。 据说这将解决任何神秘的问题。 然而，计算机并不是魔法。 如果您的代码无法正常工作，那是有原因的，只有谨慎、批判性思维才能解决问题。 拒绝盲目尝试解决方案的诱惑，直到某些事情似乎奏效为止； 通常你只是掩盖了问题而不是解决了问题。
应该有一种——最好只有一种——显而易见的方法来做到这一点。
这是对 Perl 编程语言的座右铭的猛烈抨击：“实现它的方法不止一种！” 事实证明，用三种或四种不同的方式来编写做同样事情的代码是一把双刃剑：您可以灵活地编写代码，但现在您必须学习每一种可能的编写方式，以便按顺序编写阅读它。 这种灵活性不值得学习编程语言所需的 3 倍或 4 倍的努力。
尽管除非您是荷兰人，否则这种方式一开始可能并不明显。
这条线是个笑话。 Python 的创造者和 BDFL（Benevolent Dictator for Life）的 Guido van Rossum 是荷兰人。 然而，即使是这句格言也不能阻止 Python 合并三种不同的格式化字符串的方式。
现在总比没有好。 尽管从来没有比*现在*更好。
这两个格言告诉我们，挂起或陷入无限循环的代码显然比没有挂起或陷入无限循环的代码更糟糕。 但是，等待程序完成几乎肯定比让它过早完成并产生错误结果要好。
如果实现难以解释，那就不是一个好主意。 如果实现很容易解释，那可能是个好主意。
Python 努力让程序员的工作更轻松，而不是让计算机适应程序运行得更快。 程序不仅需要编写程序的程序员能够理解，还需要维护代码的其他程序员能够理解。 这两句格言提醒我们，如果“高性能”代码复杂到程序员无法理解和调试的程度，那么它就是糟糕的代码。 但遗憾的是，仅仅因为向其他人解释程序代码很容易并不意味着它不是糟糕的代码。 编程很难。
命名空间是一个很棒的想法——让我们做更多这样的事情吧！
命名空间（以及全局和局部作用域）是防止一个模块或作用域中的名称与另一个模块或作用域中的名称冲突的关键。 但也请记住，扁平化优于嵌套式：尽管它们很出色，但命名空间应该只是为了防止命名冲突，而不是添加不必要的分类。
就像所有关于编程的观点一样，我在这里写的那些观点可能会受到反对，或者可能与您的情况无关。 争论应该如何编写代码很少像您认为的那样富有成效。 （除非你正在写一本充满编程观点的书。）
