python语言设计哲学有哪些

哲学有哪些"/>

python语言设计哲学有哪些

在Python shell中输入import this就会在屏幕上打印出来Python的设计哲学，如下：

In [25]: 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!

大概意思大家可以看一下，也可以大概的理解Python为什么是这样的，同时，我们写的代码应该是什么样的了。

今天突然好奇是怎么实现的，于是就探究了一下，先看this是啥：

In [3]: this

Out[3]:

In [4]: type(this)

Out[4]: module

In [5]: from this import

c d i s

可以看出来是一个模块，里边有这几个变量，同时我们可以根据路径去看this.py的内容，如下：

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

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])

打开第一反应是一脸懵逼，还以为整的其他语言呢，一看下面有一小段代码，实际上是简单的加密算法，仅仅做了简单的位移，类似于维吉尼亚加密～然后可以在终端试一下dir(this)，如下：

In [5]: from this import

c d i s

In [5]: from this import d

In [6]: d

Out[6]:

{'A': 'N',

'B': 'O',

'C': 'P',

'D': 'Q',

'E': 'R',

'F': 'S',

然后为什么引入其他模块没有不会直接执行print呢？我猜是底层做了区分…这个需要看Python源码，待我回头探究一下回来补充(真的会回来么

PS：

汉语版翻译见(.html)，此处摘抄如下：

The Zen of Python, by Tim Peters

Python 的设计哲学，作者：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.

虽然这种方式开始时并不容易，除非你是 Python 之父。

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!

就像命名空间就是一个绝妙的想法，应当多加利用。