python 之禅

之前在学习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!
名称空间是一个好东西——让我们做更多那样的东西!

Don't reinvent the wheel

Before writing any code,
➔ ➔ ➔ ➔
Check Python's standard library.

Check the Python Package Index (the "Cheese Shop"):

http://cheeseshop.python.org/pypi

Search the web. Google is your friend.

python 八荣八耻

以动手实践为荣 , 以只看不练为耻;  
以打印日志为荣 , 以单步跟踪为耻;  
以空格缩进为荣 , 以制表缩进为耻;  
以单元测试为荣 , 以人工测试为耻;  

以模块复用为荣 , 以复制粘贴为耻;  
以多态应用为荣 , 以分支判断为耻;  
以Pythonic为荣 , 以冗余拖沓为耻;  
以总结分享为荣 , 以X求其解为耻;  

评论

17 楼 xieye 2011-05-11  

if(i!=我){} 写道

一般情况下，一开始就接触面向对象思想的人很难适应PHP、Python这些语言。

原来我不一般。。

其实没什么的，照样可以用php，python开放OO的程序，高兴就好。

16 楼 yoyocmh1 2011-05-06  

python之禅 
总结得很好，也适用于其他语言的开发

15 楼 hwx521 2011-05-05  

applepaihs 写道

同情一下LS的，俺也是写java的，现在刚开始看Python。。。

从java到python编写代码还习惯啦？上手快吗？

14 楼 盖茨他爹 2011-01-30  

如果没有盗版心理洁癖，强烈建议用WingIDE，破解很容易，支持 indentation guide，智能提示也很棒

13 楼 jitabc 2011-01-28  

quhxuxm.quh 写道

我对Python语言一直感觉到很无奈，前些阶段因为项目需要编写了一些Python脚本，说句实在话，这个语言给我的感觉就是：做了一场噩梦，真的，没有贬低这门语言的意思，只是觉得他实在是太难维护了，特别是语句的层次是使用缩进完成的，看得我眼花。

不过这门语言被广泛的用在WLST中，我觉得这点很重要，也是我不得不去学习他的原因，有了他我才能更深入的了解到Weblogic内部的结构，但也仅此而已了。

因此，站在工业角度，我觉得这种语言还是能不用就不用，维护起来成本很高，建议各个公司的管理者也都理智一些，不要人云亦云的认为奇特，新潮的脚本语言就是编程语言的发展趋势，真所谓是：苦了程序员，又乐不到用户

哥们你搞错了吧，python的强制缩进是用来控制代码风格，避免强烈的个人风格。拿python开发东西Quick and not Dirty.

12 楼 if(i!=我){} 2011-01-20  

一般情况下，一开始就接触面向对象思想的人很难适应PHP、Python这些语言。

11 楼 smartkenny 2011-01-19  

smartkenny 写道

抱歉，没有贬低您的意思。我只是想强调好的设计对可维护性的重要性。冒犯之处请包含。

我曾经两次想学 python 都放弃了，原因是每次一看到那个缩进，我就禁不住骂 “what the fuc king ....”。等到第三次终于耐下心来学上手了，才发现这个缩进其实很是不错。可是就算你是 python 大牛，用不支持 indentation guide 的编辑器我觉得也不容易进行 code review。pydev 做的还不错，但是好象不支持 indentation guide。jedit 支持，但是其它方面就比较弱。indentation guide 最大的好处是让缩进块的层次一目了然。

软件开发要选对语言。如果你用 python 开发的软件库可维护性很差，如果不是设计问题，那就是选错了语言。没有哪个语言是完美的，我们应该按实际需要来选择语言。我觉得 python 主要是一种 glue 语言，主要的优点就是简单方便，缺点是性能比 java 这样的静态语言差很多，IDE 支持也不足。

变量的追踪可以用自动化的 pylint，当然不要指望能达到 java 这样的静态语言的程度。

至于实际使用中的可维护性，我觉得单靠语言也是不够的，还需要架构设计、文档和 code review。

抱歉没法建议一个真正符合你的 IDE。我自己一般是用 jedit。python 的 api 一般都很简单也很好记，所以很少需要用到自动提示。

quhxuxm.quh 写道

首先说一下，俺不是来打口水战的，那种帖子看多了没意思。俺是真的被这语言折磨得不行了。俺好歹也编了七八年的程序，好代码，赖代码也编了一堆，对于程序内部的逻辑和架构的合理性俺还是有自信的。

说实话，我接触Python时间不长，以前一直编Java，所以或多或少会把Python和Java比较。咱们不说什么架构，效率之类的在这里显得很苍白的东西，咱们只说支持Python的IDE。

我现在用eclipse加上Weblogic插件编写Python和WLST脚本，我找了很多编辑器，经过比较最终觉得eclipse还算可以，但是即使这样还是有几点我不是很满意：

1. API的自动提示功能很差，几乎就没有。
2. 缩进几乎变成了整个语言的关键字，虽然eclipse有比较强大的编辑功能，也能够显示空格和Tab，但是脚本文件一大起来好多循环和判断光看缩进就够看一阵子的。
3. 语法错误检查很差，经常会有莫名其妙的报错，但是实际上语法是没问题的，比如下面的语句：

def __new__(clazz):
    return object.__new__(clazz);

def __new__ 这一行竟然还会报错，而实际上这在语法上没有问题，所以我觉得很可能是大部分人使用Python编写面向过程的脚本，而我编写的是面向对象的API库，因此对于eclipse来说这一行语句属于极少被调用的，所以eclipse也没有测试过。

4. 单独使用Python还算好，万一把Jython也加进来整个代码就变得更让人恶心，由于过于弱化语言的结构与类型检查，很多变量到后来几乎难辨类型，IDE的检查几乎就更不起作用了，在维护时好多代码要从头看起才能够明白，对于有经验的程序员还好，对于新人来说这种代码看起来绝对头大。

我写Python的时间不长，而且也不是我的主要工作，我主要还是写Java，因此经常会用考虑Java的想法来考虑Python，希望高人能指点一个强大一点的IDE，让我领略一下Python真正的优美之处，而不是一味的对我这种在实际工作中碰到了问题的人进行贬低。

试了一下 Eric Python IDE，也许能满足一部分你的需要：http://eric-ide.python-projects.org/eric-download.html 在 ubuntu 下安装很简单。有 indentation guide，也有自动补全。

还有这个是老牌的了，不过是商业版：http://www.wingware.com/

10 楼 smartkenny 2011-01-19  

抱歉，没有贬低您的意思。我只是想强调好的设计对可维护性的重要性。冒犯之处请包含。

我曾经两次想学 python 都放弃了，原因是每次一看到那个缩进，我就禁不住骂 “what the fuc king ....”。等到第三次终于耐下心来学上手了，才发现这个缩进其实很是不错。可是就算你是 python 大牛，用不支持 indentation guide 的编辑器我觉得也不容易进行 code review。pydev 做的还不错，但是好象不支持 indentation guide。jedit 支持，但是其它方面就比较弱。indentation guide 最大的好处是让缩进块的层次一目了然。

软件开发要选对语言。如果你用 python 开发的软件库可维护性很差，如果不是设计问题，那就是选错了语言。没有哪个语言是完美的，我们应该按实际需要来选择语言。我觉得 python 主要是一种 glue 语言，主要的优点就是简单方便，缺点是性能比 java 这样的静态语言差很多，IDE 支持也不足。

变量的追踪可以用自动化的 pylint，当然不要指望能达到 java 这样的静态语言的程度。

至于实际使用中的可维护性，我觉得单靠语言也是不够的，还需要架构设计、文档和 code review。

抱歉没法建议一个真正符合你的 IDE。我自己一般是用 jedit。python 的 api 一般都很简单也很好记，所以很少需要用到自动提示。

quhxuxm.quh 写道

首先说一下，俺不是来打口水战的，那种帖子看多了没意思。俺是真的被这语言折磨得不行了。俺好歹也编了七八年的程序，好代码，赖代码也编了一堆，对于程序内部的逻辑和架构的合理性俺还是有自信的。

说实话，我接触Python时间不长，以前一直编Java，所以或多或少会把Python和Java比较。咱们不说什么架构，效率之类的在这里显得很苍白的东西，咱们只说支持Python的IDE。

我现在用eclipse加上Weblogic插件编写Python和WLST脚本，我找了很多编辑器，经过比较最终觉得eclipse还算可以，但是即使这样还是有几点我不是很满意：

1. API的自动提示功能很差，几乎就没有。
2. 缩进几乎变成了整个语言的关键字，虽然eclipse有比较强大的编辑功能，也能够显示空格和Tab，但是脚本文件一大起来好多循环和判断光看缩进就够看一阵子的。
3. 语法错误检查很差，经常会有莫名其妙的报错，但是实际上语法是没问题的，比如下面的语句：

def __new__(clazz):
    return object.__new__(clazz);

def __new__ 这一行竟然还会报错，而实际上这在语法上没有问题，所以我觉得很可能是大部分人使用Python编写面向过程的脚本，而我编写的是面向对象的API库，因此对于eclipse来说这一行语句属于极少被调用的，所以eclipse也没有测试过。

4. 单独使用Python还算好，万一把Jython也加进来整个代码就变得更让人恶心，由于过于弱化语言的结构与类型检查，很多变量到后来几乎难辨类型，IDE的检查几乎就更不起作用了，在维护时好多代码要从头看起才能够明白，对于有经验的程序员还好，对于新人来说这种代码看起来绝对头大。

我写Python的时间不长，而且也不是我的主要工作，我主要还是写Java，因此经常会用考虑Java的想法来考虑Python，希望高人能指点一个强大一点的IDE，让我领略一下Python真正的优美之处，而不是一味的对我这种在实际工作中碰到了问题的人进行贬低。

9 楼 applepaihs 2011-01-18  

同情一下LS的，俺也是写java的，现在刚开始看Python。。。

8 楼 quhxuxm.quh 2011-01-18  

smartkenny 写道

楼主这个翻译水平实在让人热血沸腾。
flyingzl 给的那个翻译可以说是信雅达，读了让人神清气爽，多谢了。
这段文字实际上是英文的一种诗体风格，上下句之间是有逻辑关联的，孤立来翻有时就不知所云。

那位以缩进抱怨 python 可维护性的老兄，建议你换一个支持 indentation guide 的编辑器，比如 jedit 加上一个叫做 space 的插件。python 的可维护性是很不错的了。当然，一个蹩脚的程序员不论用什么语言都写不出可维护的代码。

首先说一下，俺不是来打口水战的，那种帖子看多了没意思。俺是真的被这语言折磨得不行了。俺好歹也编了七八年的程序，好代码，赖代码也编了一堆，对于程序内部的逻辑和架构的合理性俺还是有自信的。

说实话，我接触Python时间不长，以前一直编Java，所以或多或少会把Python和Java比较。咱们不说什么架构，效率之类的在这里显得很苍白的东西，咱们只说支持Python的IDE。

我现在用eclipse加上Weblogic插件编写Python和WLST脚本，我找了很多编辑器，经过比较最终觉得eclipse还算可以，但是即使这样还是有几点我不是很满意：

1. API的自动提示功能很差，几乎就没有。
2. 缩进几乎变成了整个语言的关键字，虽然eclipse有比较强大的编辑功能，也能够显示空格和Tab，但是脚本文件一大起来好多循环和判断光看缩进就够看一阵子的。
3. 语法错误检查很差，经常会有莫名其妙的报错，但是实际上语法是没问题的，比如下面的语句：

def __new__(clazz):
    return object.__new__(clazz);

def __new__ 这一行竟然还会报错，而实际上这在语法上没有问题，所以我觉得很可能是大部分人使用Python编写面向过程的脚本，而我编写的是面向对象的API库，因此对于eclipse来说这一行语句属于极少被调用的，所以eclipse也没有测试过。

4. 单独使用Python还算好，万一把Jython也加进来整个代码就变得更让人恶心，由于过于弱化语言的结构与类型检查，很多变量到后来几乎难辨类型，IDE的检查几乎就更不起作用了，在维护时好多代码要从头看起才能够明白，对于有经验的程序员还好，对于新人来说这种代码看起来绝对头大。

我写Python的时间不长，而且也不是我的主要工作，我主要还是写Java，因此经常会用考虑Java的想法来考虑Python，希望高人能指点一个强大一点的IDE，让我领略一下Python真正的优美之处，而不是一味的对我这种在实际工作中碰到了问题的人进行贬低。

7 楼 smartkenny 2011-01-17  

楼主这个翻译水平实在让人热血沸腾。
flyingzl 给的那个翻译可以说是信雅达，读了让人神清气爽，多谢了。
这段文字实际上是英文的一种诗体风格，上下句之间是有逻辑关联的，孤立来翻有时就不知所云。

那位以缩进抱怨 python 可维护性的老兄，建议你换一个支持 indentation guide 的编辑器，比如 jedit 加上一个叫做 space 的插件。python 的可维护性是很不错的了。当然，一个蹩脚的程序员不论用什么语言都写不出可维护的代码。

6 楼 hellolaojiang 2011-01-17  

貌似豆瓣就在用。

5 楼 rubynroll 2011-01-17  

> # Readability counts. 
> # 可读写的计数。 

Here the 'counts' means "important, having positive (and also significant) contributing to".

4 楼 flyaswish 2011-01-17  

flyingzl 写道

#coding=utf-8

s = """Gur Mra bs Clguba, ol Gvz Crgref
 
Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!


python之禅

优美胜于丑陋（以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）
当存在多种可能，不要尝试去猜测,而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）
 
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
 
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
 
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召） 


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!
"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i + c)] = chr((i + 13) % 26 + c)
print "".join([d.get(c, c) for c in s])

中文中夹杂的英文字母也会被转换

3 楼 quhxuxm.quh 2011-01-17  

我对Python语言一直感觉到很无奈，前些阶段因为项目需要编写了一些Python脚本，说句实在话，这个语言给我的感觉就是：做了一场噩梦，真的，没有贬低这门语言的意思，只是觉得他实在是太难维护了，特别是语句的层次是使用缩进完成的，看得我眼花。

不过这门语言被广泛的用在WLST中，我觉得这点很重要，也是我不得不去学习他的原因，有了他我才能更深入的了解到Weblogic内部的结构，但也仅此而已了。

因此，站在工业角度，我觉得这种语言还是能不用就不用，维护起来成本很高，建议各个公司的管理者也都理智一些，不要人云亦云的认为奇特，新潮的脚本语言就是编程语言的发展趋势，真所谓是：苦了程序员，又乐不到用户

2 楼 flyingzl 2011-01-15  

#coding=utf-8

s = """Gur Mra bs Clguba, ol Gvz Crgref
 
Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!


python之禅

优美胜于丑陋（以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）
当存在多种可能，不要尝试去猜测,而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）
 
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
 
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
 
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召） 


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!
"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i + c)] = chr((i + 13) % 26 + c)
print "".join([d.get(c, c) for c in s])

1 楼 thea 2011-01-14  

Simple is better than complex. 
简单比负责要好。 
Complex is better than complicated. 
负责要比搞复杂要好