What is Pythonic?(Pythonic是什么东东?)

What is Pythonic?

作者:Martijn Faassen

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

“Pythonic”到底是什么意思?这个问题几个月前出现在EuroPython 邮件列表,EuroPython 邮件列表主要是用来计划EuroPython 会议的邮件列表。这是个很有意思的问题,我看到这个词被到处使用,但是很少有人能够尝试给出解释。随后,许多人这也包括我对“Pythonic”这个词给出自己的解释。我修饰了一下答案,并把它放在博客上,希望它对您们有用。 “Pythonic” 是一个很模糊的概念,尽管还没有“智能”或“生命”那么模糊。当你试着给出它们定义的时候,发现会无从下手。尽管它难以定义,并不意味着它们没用,事实上人们极善于处理混乱的定义。“Pythonic” 有点像“Python惯用法”的意思,现在我们需要进一步阐述“Pythonic”的蕴含。 随着时间的推移,Python持续地改进以及社区不断地成长,许多关于如何正确地和有效地使用 Python 的奇思妙想就顺应而出。一方面 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