python pythonic是什么？

 原文地址：http://faassen.n--tree.net/blog/view/weblog/2005/08/06/0

注：Martijn 是 Zope 领域的专家，他为 Zope 系列产品作了许多开发工做，也开发了 lxml 等多个开源产品。你能够在这里了解一下他的信息http://www.zope.org/Members/faassen。这篇文章写于 2005 年，虽然有少部份内容（主要是例子）看起来已经有些过期，但即使是在今天，它的中心思想依然有极高的指导意义。

这是几个月前在 EuroPython 邮件列表（主要用来组织和计划 EuroPython 会议的邮件列表）出现的问题。这是一个很是有意思的问题，我看到这个词被无数次地使用，但鲜有人尝试解释它的含义。在这条线索以后，许多不一样的人，包括我本身，都给出了本身的答案。如今我把个人答案放到博客上，而且润色了一下，但愿它能对您有所增益。

Pythonnic 是一个模糊的概念，尽管没有“智能”或“生命”那么模糊，但当你尝试定义它们的时候，就像去抓住一条滑溜溜的泥鳅同样无从下手。但是虽然它们难以定义，然而并不意味着它们没用，由于事实上人们其实极善于利用混乱的定义。Pythonic 有点像“Python惯用法”的意味，如今让咱们来聊聊它真正的含义。

随着时间的推移，Python语言不断演进，社区不断成长，涌现了许多关于如何正确地使用Python 的 ideas。一方面 Python 语言推荐使用大量的惯用法来完成任务（“完成任务的惟一方法”），另外一方面，社区不断演变的新的惯用法的又反过来影响了语言的进化，以更好地支持惯用法。好比新进入的字典的 .get() 方法，它把 has_key() 和元素存取两个操做组合为一个操做，从中能够看出这种进化。

惯用法每每不能直接从其它编程语言移植过来。以下文是实现对一个序列里的每一个元素执行一个操做的 C 语言实现：

for (i=0; i < mylist_length; i++) {

   do_something(mylist[i]);

}

直接的等效 Python 代码是这样的：

i = 0

while i < mylist_length:

   do_something(mylist[i])

   i += 1

这段代码可以完成工做，但并不 Pythonic，它并非 Python 语言推荐的惯用法。让咱们来改进一下。典型的 Python 惯用法是用内置的 range() 函数生成全部的序列下标：

for i in range(mylist_length):

   do_something(mylist[i])

其实这种实现也并不 Pythonic，接下来你们看看语言推荐的实现方式，真正 Pythonic 实现：

for element in mylist:

   do_something(element)

 “如何直接传递或改变引用”是comp.lang.python 的“月经贴”，但在只有赋值（import、class、def 等语句也可视为赋值）的 Python 中这是不可能的。这种需求一般是由于想让函数返回多个值，用 C 或者许多其它编程语言的方法是给这个函数传入引用或指针：

void foo(int* a, float* b) {

    *a = 3;

    *b = 5.5;

}

...

int alpha;

int beta;

foo(&alpha, &beta);

在 Python 中能够用很囧很恶心的方法来实现：经过给函数传递序列参数来返回结果。写出来的代码可能像这样：

def foo(a, b):

    a[0] = 3

    b[0] = 5.5

 

alpha = [0]

beta = [0]

foo(alpha, beta)

alpha = alpha[0]

beta = beta[0]

显然这是毫无 Pythonic 可言的实现。Python 中让函数返回多个值的惯用法与此迥异，得益于元组和元组解包，它看起来也要漂亮得多：

def foo():

    return 3, 5.5

 

alpha, beta = foo()

在经验老到的 Python 程序员看来，不够 Pythonic 的代码每每看起来古怪并且累赘，过于冗余也难以理解。由于它使用冗长的代码代替常见的、公认的、简短的惯用法来实现预期效果。更甚于此的是在语言支持正确的惯用法以后，非推荐的代码一般执行起来更慢。

Pythonic 就是以清晰、可读的惯用法应用Python 理念和数据结构。举个例子，应该多使用动态类型，在无必要之处引入静态类型就走向了另外一端。另外也要避免使用经验丰富的 Python 程序员不熟悉的方式去完成任务（即遵循最小惊奇原则）。

Pythonic 一词也可以适用于底层的惯用法。一个 Pythonic 的库或框架能使程序员更加容易、更加天然地学会利用它来完成任务。若是用 Python 编写的库或框架迫使程序员编写累赘的或不推荐的代码，那么能够说它并不Pythonic。也许多是为了使这个库更加方便、易懂，而没有应用Python 的一些理念，如类等，那也是不 Pythonic 的。类定义应当尽量地实现信息隐藏，虽然Python 的许多操做都只做“宽松限制”（一般由程序员在属性的前面加上一个下划线来暗示这是私有成员），但也要作得像 Java 那样严格。

固然，当规模很大的时候，它是否 Pythonic 就极具争议性了。这里给出一些参考条款：如减小冗余，Python 的库与 APIs 都倾向于小型化和轻量化（相对于 java 程序库而言）。重量级的、API过于细化的的Python 库并不 Pythonic。好比 W3C XML DOM API，尽管它的 Python 实现已经很有时日，但你们并不认为它 Pythonic。有些人认为它是 Java 式的，虽然也有许多 Java 程序员认为并不如此。

一个Pythonic的框架不会对已经用惯用法完成的东西重复发明轮子，并且它也遵循经常使用的Python 惯例。

固然，问题是构建框架时确定会不可能避免地引入一些你不熟悉的模式和方法。Zope2 是我极为熟悉的一个框架，它也是一个引入了许多完成工做的特定的方法（如 Acquisition）的例子，这些方法每每什么地方都用不到，所以许多经验丰富的 Python 程序员认为它并不 Pythonic。

建立 Pythonic 的框架极其困难，什么理念更酷、更符合语言习惯对此毫无帮助，事实上这些年来优秀的 Python 代码的特性也在不断演化。好比如今认为像 generators、sets、unicode strings 和 datetime 之类的特性尤其 Pythonic。Zope2 的历史悠久，它从1997年开始开发，你不能把不够 Pythonic 归咎于它，甚至考虑到这么多年来它控制得如此之好，更应该感谢它。

关于 Pythonicness 的新趋势的一个例子是Python 的包和模块结构日益规范化。新的代码库如Twisted、Zope3 和 PyPy 等或多或少都跟随了这样的潮流：

• 包和模块的命名采用小写，单数形式，并且短小。
• 包一般仅仅做为命名空间，如只包含空的 __init__.py 文件。

在我写库（如 lxml）的时候也遵循了这样的惯例。

由于更多人认为一个 Python 程序员容易学习的功能不那么强大的框架比一个须要大量时间来学习的强大系统更为 pythonic。因此有时我认为宣称软件不够 Pythonic 不公平，甚至可能会所以而掩盖了该软件积极的一面。

最后，做为何是 Pythonic 的扩充材料，能够尝试一下在 Python 解释器里执行以下语句：

import this

译者：赖勇浩（http://blog.csdn.net/lanphaday）

import this内容：

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! 

– by Tim Peters

翻译：

优美胜于丑陋（Python 以编写优美的代码为目标）

明了胜于晦涩（优美的代码应当是明了的，命名规范，风格类似）

简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）

复杂胜于凌乱（若是复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）

扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）

间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）

可读性很重要（优美的代码是可读的）

即使假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）

 

不要包容全部错误，除非你肯定须要这样作（精准地捕获异常，不写 except:pass 风格的代码）

 

当存在多种可能，不要尝试去猜想

而是尽可能找一种，最好是惟一一种明显的解决方案（若是不肯定，就用穷举法）

虽然这并不容易，由于你不是 Python 之父（这里的 Dutch 是指 Guido ）

 

作也许好过不作，但不假思索就动手还不如不作（动手以前要细思量）

 

若是你没法向人描述你的方案，那确定不是一个好方案；反之亦然（方案测评标准）

 

命名空间是一种绝妙的理念，咱们应当多加利用（倡导与号召）

来源：http://wiki.woodpecker.org.cn/moin/PythonZen