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.
> 虽然这并不容易，因为你不是 Python 之父（这里的荷兰人是指Guido）
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!
> 命名空间是一种绝妙的理念，我们应多加利用
