Python 之禅

还有很多不会翻译,或者翻译错误,请大家懂得的指正一下,谢谢

Beautiful is better than ugly.

魅力比丑陋更好

Explicit is better than implicit.

显式比隐式更好

Simple is better than complex.

简单比复杂更好

Flat is better than nested.

平滑比嵌套更好

Sparse is better than dense.

稀疏比稠密更好

Readablility counts.

可读性 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.

实现容易被解释是一个好注意


<think>我们被要求查看Python。根据引用,PythonPython语言的核心设计哲学,由TimPeters编写。我们可以直接在Python解释器中输入`importthis`来查看。但是用户可能希望我们直接展示出来,并且提供解释。根据引用[3],我们有Python的中文翻译和解释。因此,我们将展示Python的英文原文和中文翻译,并附上简要解释。注意:由于引用[3]已经提供了中文翻译和解释,我们可以直接引用,并在末尾标注引用来源。另外,根据系统级指令,我们需要在回答中自然地添加引用标识,例如[^3]。同时,我们需要生成相关问题。步骤:1.展示Python的英文原文(通过`importthis`输出的内容)。2.展示引用[3]提供的中文翻译和解释(但注意不要完全复制,而是整合成清晰的形式)。3.在末尾生成相关问题。注意:由于引用[3]的翻译已经比较完整,我们直接采用,但可以稍作整理。但是,由于用户要求查看Python,我们应首先展示其内容。我们可以用代码块展示英文,然后用引用[3]的中文解释。由于引用[3]的翻译是逐条对应的,我们可以这样展示:英文:TheZenofPython,byTimPetersBeautifulisbetterthanugly.Explicitisbetterthanimplicit.Simpleisbetterthancomplex.Complexisbetterthancomplicated.Flatisbetterthannested.Sparseisbetterthandense.Readabilitycounts.Specialcasesaren'tspecialenoughtobreaktherules.Althoughpracticalitybeatspurity.Errorsshouldneverpasssilently.Unlessexplicitlysilenced.Inthefaceofambiguity,refusethetemptationtoguess.Thereshouldbeone--andpreferablyonlyone--obviouswaytodoit.Althoughthatwaymaynotbeobviousatfirstunlessyou'reDutch.Nowisbetterthannever.Althoughneverisoftenbetterthan*right*now.Iftheimplementationishardtoexplain,it'sabadidea.Iftheimplementationiseasytoexplain,itmaybeagoodidea.Namespacesareonehonkinggreatidea--let'sdomoreofthose!然后,我们逐条给出中文翻译和解释(根据引用[3]整理)。但是,为了避免回答过长,我们可以将中文翻译以列表形式呈现,并在每一条后面简要解释(解释部分可以简化,因为引用[3]已经解释得很清楚)。然而,根据引用[3]的翻译,它已经包含了翻译和解释。我们可以这样:由于引用[3]的翻译和解释是混合的,我们可以直接引用它的翻译部分(即每句后面的括号内容),但注意版权问题,这里我们只是展示用户已经提供的引用内容。因此,我们可以这样组织:先展示英文,然后展示中文翻译(不带括号内的解释),然后在下面给出一个解释的列表(将引用[3]括号内的内容作为解释)。但为了简洁,也可以将英文和中文翻译并列展示,然后整体给出一个解释的段落。考虑到清晰度,我们采用以下方式:1.展示英文原文(用代码块)2.展示中文翻译(用引用[3]的翻译,用引用块或者列表)3.对其中一些重要原则进行简要说明(可以引用引用[3]的解释)但是,用户要求查看Python,所以主要是展示内容。我们可以将中文翻译直接对应在英文每句的后面,用注释的方式。然而,这样可能会很乱。因此,我们决定分别展示:首先,我们可以在Python中执行`importthis`来得到这些内容,但既然用户现在看不到,我们就直接输出。我们按照引用[3]提供的中文翻译,逐句对应英文列出。但是,引用[3]的翻译是19句,而英文也是19句。我们可以这样:英文和中文对照表:1.Beautifulisbetterthanugly.->优美胜于丑陋2.Explicitisbetterthanimplicit.->明了胜于晦涩3.Simpleisbetterthancomplex.->简洁胜于复杂4.Complexisbetterthancomplicated.->复杂胜于凌乱5.Flatisbetterthannested.->扁平胜于嵌套6.Sparseisbetterthandense.->间隔胜于紧凑7.Readabilitycounts.->可读性很重要8.Specialcasesaren'tspecialenoughtobreaktherules.->即便假借特例的实用性之名,也不可违背这些规则9.Althoughpracticalitybeatspurity.->虽然实用性次于纯粹性(注:引用[3]没有这一句的单独翻译,但英文有这一句,而且引用[3]在第八句的翻译中已经包含了两句的意思?实际上,引用[3]的第八句翻译对应的是第八句英文,而第九句英文在引用[3]中没有单独翻译,而是与第八句合并了?)实际上,引用[3]的翻译文本中并没有逐句对应,而是将一些句子合并解释了。比如,它把第8句和第9句合并为一条。因此,我们重新审视引用[3]:引用[3]的翻译和解释是:优美胜于丑陋(Python以编写优美的代码为目标)明了胜于晦涩(优美的代码应当是明了的,命名规范,风格相似)简洁胜于复杂(优美的代码应当是简洁的,不要有复杂的内部实现)复杂胜于凌乱(如果复杂不可避免,那代码间也不能有难懂的关系,要保持接口简洁)扁平胜于嵌套(优美的代码应当是扁平的,不能有太多的嵌套)间隔胜于紧凑(优美的代码有适当的间隔,不要奢望一行代码解决问题)可读性很重要(优美的代码是可读的)即便假借特例的实用性之名,也不可违背这些规则(这些规则至高无上)不要包容所有错误,除非你确定需要这样做(精准地捕获异常,不写except:pass风格的代码)当存在多种可能,不要尝试去猜测而是尽量找一种,最好是唯一一种明显的解决方案(如果不确定,就用穷举法)虽然这并不容易,因为你不是Python之父(这里的Dutch是指Guido)做也许好过不做,但不假思索就动手还不如不做(动手之前要细思量)如果你无法向人描述你的方案,那肯定不是一个好方案;反之亦然(方案测评标准)命名空间是一种绝妙的理念,我们应当多加利用(倡导与号召)注意:这里的中文翻译并没有严格按照19句来,而是将一些句子合并了。例如,原英文的第8句和第9句合并为第8条(即“即便假借特例的实用性之名,也不可违背这些规则”),而第10句和第11句合并为第9条(不要包容所有错误...),等等。因此,为了准确,我们按照引用[3]的翻译和解释来展示。但是,用户可能希望看到完整的19句的翻译。然而,引用[3]的翻译是广为接受的版本,我们可以采用。所以,我们这样展示:我们将引用[3]的翻译和解释以列表形式展示,每一条包括:-原则的中文表述(即引用[3]中每条的第一句话)-括号内的解释但是,引用[3]的翻译文本中,有些原则对应了英文的多个句子。因此,我们按照引用[3]的条目来展示。最终,我们决定展示19句英文原文,然后展示引用[3]的中文翻译(共14条)?实际上,引用[3]的条目数并不是19条,而是14条(从“优美胜于丑陋”到“命名空间是一种绝妙的理念”共14条)。所以,我们按照引用[3]的方式展示。因为引用[3]是用户提供的参考,我们可以直接采用。因此,回答如下:首先,我们可以在Python交互环境中输入`importthis`来查看Python。以下是其完整内容:###Python(TheZenofPython)原文```textTheZenofPython,byTimPetersBeautifulisbetterthanugly.Explicitisbetterthanimplicit.Simpleisbetterthancomplex.Complexisbetterthancomplicated.Flatisbetterthannested.Sparseisbetterthandense.Readabilitycounts.Specialcasesaren'tspecialenoughtobreaktherules.Althoughpracticalitybeatspurity.Errorsshouldneverpasssilently.Unlessexplicitlysilenced.Inthefaceofambiguity,refusethetemptationtoguess.Thereshouldbeone--andpreferablyonlyone--obviouswaytodoit.Althoughthatwaymaynotbeobviousatfirstunlessyou'reDutch.Nowisbetterthannever.Althoughneverisoftenbetterthan*right*now.Iftheimplementationishardtoexplain,it'sabadidea.Iftheimplementationiseasytoexplain,itmaybeagoodidea.Namespacesareonehonkinggreatidea--let'sdomoreofthose!```###中文翻译与解释(根据TimPeters的原意整理)[^3]1.**优美胜于丑陋**Python以编写优美的代码为目标。2.**明了胜于晦涩**优美的代码应当是明了的,命名规范,风格相似。3.**简洁胜于复杂**优美的代码应当是简洁的,不要有复杂的内部实现。4.**复杂胜于凌乱**如果复杂不可避免,那代码间也不能有难懂的关系,要保持接口简洁。5.**扁平胜于嵌套**优美的代码应当是扁平的,不能有太多的嵌套。6.**间隔胜于紧凑**优美的代码有适当的间隔,不要奢望一行代码解决问题。7.**可读性很重要**优美的代码是可读的。8.**即便假借特例的实用性之名,也不可违背这些规则**这些规则至高无上。9.**不要包容所有错误,除非你确定需要这样做**精准地捕获异常,不写`except:pass`风格的代码。10.**当存在多种可能,不要尝试去猜测,而是尽量找一种,最好是唯一一种明显的解决方案**如果不确定,就用穷举法。11.**虽然这并不容易,因为你不是Python之父**(这里的Dutch是指GuidovanRossum,Python之父,因为他是荷兰人)12.**做也许好过不做,但不假思索就动手还不如不做**动手之前要细思量。13.**如果你无法向人描述你的方案,那肯定不是一个好方案;反之亦然**这是方案的测评标准。14.**命名空间是一种绝妙的理念,我们应当多加利用**倡导与号召。>注意:以上解释是对Python的进一步阐释,帮助理解其背后的设计哲学。###如何在Python中查看```pythonimportthis```###相关问题1.如何在实际编程中运用Python的原则?2.Python中的“扁平胜于嵌套”在代码结构上如何体现?3.有哪些典型的违反Python的代码例子?4.PythonPython语言的发展产生了哪些影响?</think>### Python(The Zen of PythonPythonPython语言的核心设计哲学,由Python创始人Guido van Rossum和Tim Peters共同制定。它通过19条简洁的格言,指导开发者编写优雅、高效的Pythonic代码。以下是完整内容: #### 英文原文(通过`import this`查看) ```python >>> 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! ``` #### 中文翻译与解释 1. **优美胜于丑陋** Python以编写优美的代码为目标,注重代码的视觉美感和结构清晰[^3]。 2. **明了胜于晦涩** 代码应当明确直观,避免隐晦的逻辑(如优先使用`len()`而非魔术方法)[^3]。 3. **简洁胜于复杂** 用简单方案解决问题(如列表推导式优于多重循环): ```python # 简洁实现 squares = [x**2 for x in range(10)] ``` 4. **复杂胜于凌乱** 当问题本身复杂时,保持接口简洁(如使用装饰器封装复杂逻辑)[^3]。 5. **扁平胜于嵌套** 减少嵌套层次(深度嵌套的`if/for`应重构为函数): ```python # 避免 if condition1: if condition2: ... ``` 6. **间隔胜于紧凑** 合理使用空格提升可读性(遵循PEP8空格规范)[^3]。 7. **可读性很重要** 变量命名应自解释(如用`user_count`而非`uc`)[^1]。 8. **规则高于特例** 即使特殊情况有实用价值,也不应破坏语言一致性[^3]。 9. **精准处理错误** 避免笼统的异常捕获: ```python # 错误方式 try: ... except: # 应指定具体异常类型 pass ``` 10. **寻求唯一最佳方案** 当存在多种实现时,寻找最明确的一种(Python强调"只有一种方式")[^2]。 11. **三思而后行** 编码前充分设计,避免盲目动手(原型设计优先于直接实现)[^3]。 12. **可解释性即质量** 难以解释的实现通常是糟糕的设计(文档驱动开发)[^3]。 13. **善用命名空间** 充分利用模块化和作用域(如避免全局变量)[^2]。 #### 设计哲学核心 - **实用性 > 纯粹性**:解决实际问题优先于理论完美 - **显式 > 隐式**:明确指定行为(如`@property`装饰器优于隐式getter) - **一致性**:语言特性保持高度正交性 > Python不仅是编码规范,更是Python语言演进的基石。它解释了为什么Python拒绝`++`运算符、为什么强制缩进、为何采用"鸭子类型"等设计决策[^2]。 ### 在代码中实践 ```python # 符合Python的示例 def calculate_average(numbers): """明确函数名+文档字符串""" if not numbers: # 显式处理边界 raise ValueError("Empty list not allowed") return sum(numbers) / len(numbers) # 简洁且可读 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值