The squares in the middle look suspicious so you think that the answer is encoded within it.

Unfortunately, Python does not have a built-in Image library so you'll have to search for an external module. I've chosen to use PIL (http://www.pythonware.com/products/pil/), which I had pre-installed.

>>> import Image, urllib, StringIO

>>> img = urllib.urlopen('http://www.pythonchallenge.com/pc/def/oxygen.png').read()

>>> i = Image.open(StringIO.StringIO(img))  # Image.open requires a file-like object

>>> i.size

(629, 95)

>>> [i.getpixel((x,45)) for x in range(629)]

[(115, 115, 115, 255), (115, 115, 115, 255), (115, 115, 115, 255), ...

There seem to be a lot of data here, but it is noticable that the grey squares have R=G=B, and it has a period of 7 pixels.

# Extract every 7th pixel from row 45.

>>> row = [i.getpixel((x, 45)) for x in range(0, i.size[0], 7)]

# Take the R value from all with equal R, G, and B values.

>>> ords = [r for r, g, b, a in row if r == g == b]

# And convert to characters.

>>> print "".join(map(chr, ords))

smart guy, you made it. the next level is [105, 110, 116, 101, 103, 114, 105, 116, 121]

Applying the hint:

>>> "".join(map(chr,[105, 110, 116, 101, 103, 114, 105, 116, 121]))

'integrity'



-------------------------------------------------------------------------------------------------------------------------------



Level 8: http://www.pythonchallenge.com/pc/def/integrity.html

上——http://www.linuxdby.com/html/linux/program/20070412/1753.html

下——http://www.linuxdby.com/html/linux/program/20070412/1754.html)

什么是持久性？

持久性的基本思想很简单。假定有一个 Python 程序，它可能是一个管理日常待办事项的程序，您希望在多次执行这个程序之间可以保存应用程序对象（待办事项）。换句话说，您希望把对象存储在磁盘上，便于 以后检索。这就是持久性。要达到这个目的，有几种方法，每一种方法都有其优缺点。

例如，可以把对象数据存储在某种格式的文本文件中，譬如 CSV 文件。或者可以用关系数据库，譬如 Gadfly、MySQL、PostgreSQL 或者 DB2。这些文件格式和数据库都非常优秀，对于所有这些存储机制，Python 都有健壮的接口。

这些存储机制都有一个共同点：存储的数据是独立于对这些数据进行操作的对象和程序。 这样做的好处是，数据可以作为共享的资源，供其它应用程序使用。缺点是，用这种方式，可以允许其它程序访问对象的数据，这违背了面向对象的封装性原则 — 即对象的数据只能通过这个对象自身的公共（public）接口来访问。

另外，对于某些应用程序，关系数据库方法可能不是很理想。尤其是，关系数据库不理 解对象。相反，关系数据库会强行使用自己的类型系统和关系数据模型（表），每张表包含一组元组（行），每行包含具有固定数目的静态类型字段（列）。如果应 用程序的对象模型不能够方便地转换到关系模型，那么在把对象映射到元组以及把元组映射回对象方面，会碰到一定难度。这种困难常被称为阻碍性不匹配 （impedence-mismatch）问题。

对象持久性

如果希望透明地存储 Python 对象，而不丢失其身份和类型等信息，则需要某种形式的对象序列化：它是一个把任意复杂的对象转成对象的文本或二进制表示的过程。同样，必须能够把对象经过 序列化后的形式恢复到原有的对象。在 Python 中，这种序列化过程称为 pickle，可以把对象 pickle 成字符串、磁盘上的文件或者任何类似于文件的对象，也可以把这些字符串、文件或任何类似于文件的对象 unpickle 成原来的对象。我们把在本文后面详细讨论 pickle。

假定您喜欢把任何事物都保存成对象，而且希望避免把对象转换成某种基于非对象存储 的开销；那么 pickle 文件可以提供这些好处，但有时可能需要比这种简单的 pickle 文件更健壮以及更具有可伸缩性的事物。例如，只用 pickle 不能解决命名和查找 pickle 文件这样的问题，另外，它也不能支持并发地访问持久性对象。如果需要这些方面的功能，则要求助类似于 ZODB（针对 Python 的 Z 对象数据库）这类数据库。ZODB 是一个健壮的、多用户的和面向对象的数据库系统，它能够存储和管理任意复杂的 Python 对象，并支持事务操作和并发控制。（请参阅参考资料，以下载 ZODB。）令人足够感兴趣的是，甚至 ZODB 也依靠 Python 的本机序列化能力，而且要有效地使用 ZODB，必须充分了解 pickle。

另一种令人感兴趣的解决持久性问题的方法是 Prevayler，它最初是用 Java 实现的（有关 Prevaylor 方面的 developerWorks 文章，请参阅参考资料）。最近，一群 Python 程序员把 Prevayler 移植到了 Python 上，另起名为 PyPerSyst，由 SourceForge 托管（有关至 PyPerSyst 项目的链接，请参阅参考资料）。Prevayler/PyPerSyst 概念也是建立在 Java 和 Python 语言的本机序列化能力之上。PyPerSyst 把整个对象系统保存在内存中，并通过不时地把系统快照 pickle 到磁盘以及维护一个命令日志（通过此日志可以重新应用最新的快照）来提供灾难恢复。所以，尽管使用 PyPerSyst 的应用程序受到可用内存的限制，但好处是本机对象系统可以完全装入到内存中，因而速度极快，而且实现起来要比如 ZODB 这样的数据库简单，ZODB 允许对象的数目比同时在能内存中所保持的对象要多。

一些经过 pickle 的 Python

pickle 模块及其同类模块 cPickle 向 Python 提供了 pickle 支持。后者是用 C 编码的，它具有更好的性能，对于大多数应用程序，推荐使用该模块。我们把继续讨论 pickle，但本文的示例实际是利用了 cPickle。由于其中大多数示例要用 Python shell 来显示，所以先展示一下怎么样导入 cPickle，并可以作为 pickle 来引用它：

  >>> import cPickle as pickle

现在已经导入了该模块，接下来让我们看一下 pickle 接口。pickle 模块提供了以下函数对：dumps(object) 返回一个字符串，它包含一个 pickle 格式的对象；loads(string) 返回包含在 pickle 字符串中的对象；dump(object, file) 把对象写到文件，这个文件可以是实际的物理文件，但也可以是任何类似于文件的对象，这个对象具有 write() 方法，可以接受单个的字符串参数；load(file) 返回包含在 pickle 文件中的对象。

缺省情况下，dumps() 和 dump() 使用可打印的 ASCII 表示来创建 pickle。两者都有一个 final 参数（可选），如果为 True，则该参数指定用更快以及更小的二进制表示来创建 pickle。loads() 和 load() 函数自动检测 pickle 是二进制格式还是文本格式。

清单 1 显示了一个交互式会话，这里使用了刚才所描述的 dumps() 和 loads() 函数：

  Welcome To PyCrust 0.7.2 - The Flakiest Python Shell

            Sponsored by Orbtech - Your source for Python programming expertise.

            Python 2.2.1 (#1, Aug 27 2002, 10:22:32)

            [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux-i386

            Type "copyright", "credits" or "license" for more information.

            >>> import cPickle as pickle

            >>> t1 = ('this is a string', 42, [1, 2, 3], None)

            >>> t1

            ('this is a string', 42, [1, 2, 3], None)

            >>> p1 = pickle.dumps(t1)

            >>> p1

            "(S'this is a string'\nI42\n(lp1\nI1\naI2\naI3\naNtp2\n."

            >>> print p1

            (S'this is a string'

            I42

            (lp1

            I1

            aI2

            aI3

            aNtp2

            .

            >>> t2 = pickle.loads(p1)

            >>> t2

            ('this is a string', 42, [1, 2, 3], None)

            >>> p2 = pickle.dumps(t1, True)

            >>> p2

            '(U\x10this is a stringK*]q\x01(K\x01K\x02K\x03eNtq\x02.'

            >>> t3 = pickle.loads(p2)

            >>> t3

            ('this is a string', 42, [1, 2, 3], None)

注：该文本 pickle 格式很简单，这里就不解释了。事实上，在 pickle 模块中记录了所有使用的约定。我们还应该指出，在我们的示例中使用的都是简单对象，因此使用二进制 pickle 格式不会在节省空间上显示出太大的效率。然而，在实际使用复杂对象的系统中，您会看到，使用二进制格式可以在大小和速度方面带来显著的改进。

接下来，我们看一些示例，这些示例用到了 dump() 和 load()，它们使用文件和类似文件的对象。这些函数的操作非常类似于我们刚才所看到的 dumps() 和 loads()，区别在于它们还有另一种能力 — dump() 函数能一个接着一个地把几个对象转储到同一个文件。随后调用 load() 来以同样的顺序检索这些对象。清单 2 显示了这种能力的实际应用：

  >>> a1 = 'apple'

            >>> b1 = {1: 'One', 2: 'Two', 3: 'Three'}

            >>> c1 = ['fee', 'fie', 'foe', 'fum']

            >>> f1 = file('temp.pkl', 'wb')

            >>> pickle.dump(a1, f1, True)

            >>> pickle.dump(b1, f1, True)

            >>> pickle.dump(c1, f1, True)

            >>> f1.close()

            >>> f2 = file('temp.pkl', 'rb')

            >>> a2 = pickle.load(f2)

            >>> a2

            'apple'

            >>> b2 = pickle.load(f2)

            >>> b2

            {1: 'One', 2: 'Two', 3: 'Three'}

            >>> c2 = pickle.load(f2)

            >>> c2

            ['fee', 'fie', 'foe', 'fum']

            >>> f2.close()

            

Pickle 的威力

到目前为止，我们讲述了关于 pickle 方面的基本知识。在这一节，把讨论一些高级问题，当您开始 pickle 复杂对象时，会遇到这些问题，其中包括定制类的实例。幸运的是，Python 可以很容易地处理这种情形。

可移植性

从空间和时间上说，Pickle 是可移植的。换句话说，pickle 文件格式独立于机器的体系结构，这意味着，例如，可以在 Linux 下创建一个 pickle，然后把它发送到在 Windows 或 Mac OS 下运行的 Python 程序。并且，当升级到更新版本的 Python 时，不必担心可能要废弃已有的 pickle。Python 开发人员已经保证 pickle 格式把可以向后兼容 Python 各个版本。事实上，在 pickle 模块中提供了有关目前以及所支持的格式方面的详细信息：

  >>> pickle.format_version

            '1.3'

            >>> pickle.compatible_formats

            ['1.0', '1.1', '1.2']

多个引用，同一对象

在 Python 中，变量是对象的引用。同时，也可以用多个变量引用同一个对象。经证明，Python 在用经过 pickle 的对象维护这种行为方面丝毫没有困难，如清单 4 所示：

  >>> a = [1, 2, 3]

            >>> b = a

            >>> a

            [1, 2, 3]

            >>> b

            [1, 2, 3]

            >>> a.append(4)

            >>> a

            [1, 2, 3, 4]

            >>> b

            [1, 2, 3, 4]

            >>> c = pickle.dumps((a, b))

            >>> d, e = pickle.loads(c)

            >>> d

            [1, 2, 3, 4]

            >>> e

            [1, 2, 3, 4]

            >>> d.append(5)

            >>> d

            [1, 2, 3, 4, 5]

            >>> e

            [1, 2, 3, 4, 5]

循环引用和递归引用

可以把刚才演示过的对象引用支持扩展到循环引用（两个对象各自包含对对方的引用）和递归引用（一个对象包含对其自身的引用）。下面两个清单着重显示这种能力。我们先看一下递归引用：

  >>> l = [1, 2, 3]

            >>> l.append(l)

            >>> l

            [1, 2, 3, [...]]

            >>> l[3]

            [1, 2, 3, [...]]

            >>> l[3][3]

            [1, 2, 3, [...]]

            >>> p = pickle.dumps(l)

            >>> l2 = pickle.loads(p)

            >>> l2

            [1, 2, 3, [...]]

            >>> l2[3]

            [1, 2, 3, [...]]

            >>> l2[3][3]

            [1, 2, 3, [...]]

现在，看一个循环引用的示例：

  >>> a = [1, 2]

            >>> b = [3, 4]

            >>> a.append(b)

            >>> a

            [1, 2, [3, 4]]

            >>> b.append(a)

            >>> a

            [1, 2, [3, 4, [...]]]

            >>> b

            [3, 4, [1, 2, [...]]]

            >>> a[2]

            [3, 4, [1, 2, [...]]]

            >>> b[2]

            [1, 2, [3, 4, [...]]]

            >>> a[2] is b

            1

            >>> b[2] is a

            1

            >>> f = file('temp.pkl', 'w')

            >>> pickle.dump((a, b), f)

            >>> f.close()

            >>> f = file('temp.pkl', 'r')

            >>> c, d = pickle.load(f)

            >>> f.close()

            >>> c

            [1, 2, [3, 4, [...]]]

            >>> d

            [3, 4, [1, 2, [...]]]

            >>> c[2]

            [3, 4, [1, 2, [...]]]

            >>> d[2]

            [1, 2, [3, 4, [...]]]

            >>> c[2] is d

            1

            >>> d[2] is c

            1

注意，如果分别 pickle 每个对象，而不是在一个元组中一起 pickle 所有对象，会得到略微不同（但很重要）的结果，如清单 7 所示：

  >>> f = file('temp.pkl', 'w')

            >>> pickle.dump(a, f)

            >>> pickle.dump(b, f)

            >>> f.close()

            >>> f = file('temp.pkl', 'r')

            >>> c = pickle.load(f)

            >>> d = pickle.load(f)

            >>> f.close()

            >>> c

            [1, 2, [3, 4, [...]]]

            >>> d

            [3, 4, [1, 2, [...]]]

            >>> c[2]

            [3, 4, [1, 2, [...]]]

            >>> d[2]

            [1, 2, [3, 4, [...]]]

            >>> c[2] is d

            0

            >>> d[2] is c

            0

相等，但并不总是相同

正如在上一个示例所暗示的，只有在这些对象引用内存中同一个对象时，它们才是相同的。在 pickle 情形中，每个对象被恢复到一个与原来对象相等的对象，但不是同一个对象。换句话说，每个 pickle 都是原来对象的一个副本：

  >>> j = [1, 2, 3]

            >>> k = j

            >>> k is j

            1

            >>> x = pickle.dumps(k)

            >>> y = pickle.loads(x)

            >>> y

            [1, 2, 3]

            >>> y == k

            1

            >>> y is k

            0

            >>> y is j

            0

            >>> k is j

            1

同时，我们看到 Python 能够维护对象之间的引用，这些对象是作为一个单元进行 pickle 的。然而，我们还看到分别调用 dump() 会使 Python 无法维护对在该单元外部进行 pickle 的对象的引用。相反，Python 复制了被引用对象，并把副本和被 pickle 的对象存储在一起。对于 pickle 和恢复单个对象层次结构的应用程序，这是没有问题的。但要意识到还有其它情形。

值得指出的是，有一个选项确实允许分别 pickle 对象，并维护相互之间的引用，只要这些对象都是 pickle 到同一文件即可。pickle 和 cPickle 模块提供了一个 Pickler（与此相对应是 Unpickler），它能够跟踪已经被 pickle 的对象。通过使用这个 Pickler，把会通过引用而不是通过值来 pickle 共享和循环引用：

  >>> f = file('temp.pkl', 'w')

            >>> pickler = pickle.Pickler(f)

            >>> pickler.dump(a)

            

            >>> pickler.dump(b)

            

            >>> f.close()

            >>> f = file('temp.pkl', 'r')

            >>> unpickler = pickle.Unpickler(f)

            >>> c = unpickler.load()

            >>> d = unpickler.load()

            >>> c[2]

            [3, 4, [1, 2, [...]]]

            >>> d[2]

            [1, 2, [3, 4, [...]]]

            >>> c[2] is d

            1

            >>> d[2] is c

            1

不可 pickle 的对象

一些对象类型是不可 pickle 的。例如，Python 不能 pickle 文件对象（或者任何带有对文件对象引用的对象），因为 Python 在 unpickle 时不能保证它可以重建该文件的状态（另一个示例比较难懂，在这类文章中不值得提出来）。试图 pickle 文件对象会导致以下错误：

  >>> f = file('temp.pkl', 'w')

            >>> p = pickle.dumps(f)

            Traceback (most recent call last):

            File "", line 1, in ?

            File "/usr/lib/python2.2/copy_reg.py", line 57, in _reduce

            raise TypeError, "can't pickle ％s objects" ％ base.__name__

            TypeError: can't pickle file objects

　　class Foo(object):

            

            def __init__(self, value):

            self.value = value

　　>>> import cPickle as pickle

            >>> from Orbtech.examples.persist import Foo

            >>> foo = Foo('What is a Foo?')

            >>> p = pickle.dumps(foo)

            >>> print p

            ccopy_reg

            _reconstructor

            p1

            (cOrbtech.examples.persist

            Foo

            p2

            c__builtin__

            object

            p3

            NtRp4

            (dp5

            S'value'

            p6

            S'What is a Foo?'

            sb.

            >>>

　　>>> import cPickle as pickle

            >>> f = file('temp.pkl', 'r')

            >>> foo = pickle.load(f)

            Traceback (most recent call last):

            File "", line 1, in ?

            AttributeError: 'module' object has no attribute 'Foo'

　　>>> import cPickle as pickle

            >>> f = file('temp.pkl', 'r')

            >>> foo = pickle.load(f)

            Traceback (most recent call last):

            File "", line 1, in ?

            ImportError: No module named persist

　　class Foo(object):

            

            def __init__(self, value, filename):

            self.value = value

            self.logfile = file(filename, 'w')

            

            def __getstate__(self):

            """Return state values to be pickled."""

            f = self.logfile

            return (self.value, f.name, f.tell())

            

            def __setstate__(self, state):

            """Restore state from the unpickled state values."""

            self.value, name, position = state

            f = file(name, 'w')

            f.seek(position)

            self.logfile = f

　　def __setstate__(self, state):

            self.__dict__.update(state)

            self.__class__ = NewClassName

　class Person(object):

            

            def __init__(self, firstname, lastname):

            self.firstname = firstname

            self.lastname = lastname

　　class Person(object):

            

            def __init__(self, fullname):

            self.fullname = fullname

            

            def __setstate__(self, state):

            if 'fullname' not in state:

            first = '

            last = '

            if 'firstname' in state:

            first = state['firstname']

            del state['firstname']

            if 'lastname' in state:

            last = state['lastname']

            del state['lastname']

            self.fullname = " ".join([first, last]).strip()

            self.__dict__.update(state)

这篇文档改编自Guido最初的《Python风格指南》一文，并从《Barry's style guide》中添加了部分内容。在有冲突的地方，Guide的风格规则应该是符合本PEP的意图(译注：指当有冲突时，应以Guido风格为准)。这篇PEP仍然尚未完成(实际上，它可能永远都不会完成)。

    在这篇风格指导中的一致性是重要的。在一个项目内的一致性更重要。在一个模块或函数内的一致性最重要。但最重要的是：知道何时会不一致——有时只是没有实施风格指导。当出现疑惑时，运用你的最佳判断，看看别的例子，然后决定怎样看起来更好。并且要不耻下问！

    打破一条既定规则的两个好理由：

(1)    当应用这个规则是将导致代码可读性下降，即便对某人来说，他已经习惯于按这条规则来阅读代码了。

(2)    为了和周围的代码保持一致而打破规则(也许是历史原因)，虽然这也是个清除其它混乱的好机会(真正的XP风格)。

代码的布局

    缩进

使用Emacs的Python-mode的默认值：4个空格一个缩进层次。对于确实古老的代码，你不希望产生混乱，可以继续使用8空格的制表符(8-space tabs)。Emacs Python-mode自动发现文件中主要的缩进层次，依此设定缩进参数。

制表符还是空格

    永远不要混用制表符和空格。最流行的Python缩进方式是仅使用空格，其次是仅使用制表符，混合着制表符和空格缩进的代码将被转换成仅使用空格。(在Emacs中，选中整个缓冲区，按ESC-x去除制表符。)调用Python命令行解释器时使用-t选项，可对代码中不合法得混合制表符和空格发出警告，使用-tt时警告将变成错误。这些选项是被高度推荐的。

    对于新的项目，强烈推荐仅使用空格而不是制表符。许多编辑器拥有使之易于实现的功能(在Emacs中，确认indent-tabs-mode是nil)。

行的最大长度

    周围仍然有许多设备被限制在每行80字符：而且，窗口限制在80个字符。使将多个窗口并排放置成为可能。在这些设备上使用默认的折叠方式看起来有点丑陋。因此，请将所有行限制在最大79字符(Emacs准确得将行限制为长80字符)，对顺序排放的大块文本(文档字符串或注释)，推荐将长度限制在72字符。

    折叠长行的首选方法是使用Pyhon支持的圆括号，方括号和花括号内的行延续。如果需要，你可以在表达式周围增加一对额外的圆括号，但是有时使用反斜杠看起来更好，确认恰当得缩进了延续的行。

    Emacs的Python-mode正确得完成了这些。一些例子：

#!Python

    class Rectangle(Blob)：

        def __init__(self，width，height，color='black'，emphasis=None，highlight=0)：

            if width == 0 and height == 0 and \

               color == 'red' and emphasis == 'strong' or \

               highlight > 100：

                raise ValueError， "sorry， you lose"

            if width == 0 and height == 0 and (color == 'red' or

                                               emphasis is None)：

                raise ValueError，"I don't think so"

            Blob.__init__(self，width，height，color，emphasis，highlight)

空行

    用两行空行分割顶层函数和类的定义，类内方法的定义用单个空行分割，额外的空行可被用于(保守的)分割相关函数组成的群，在一组相关的单句中间可以省略空行。(例如：一组哑元素)。

    当空行用于分割方法的定义时，在‘class’行和第一个方法定义之间也要有一个空行。在函数中使用空行时，请谨慎的用于表示一个逻辑段落。Python接受contol-L(即^L)换页符作为空格：Emacs(和一些打印工具)，视这个字符为页面分割符，因此在你的文件中，可以用他们来为相关片段分页。

编码

    Python核心发布中的代码必须始终使用ASCII或Latin-1编码(又名 ISO-8859-1)，使用ASCII的文件不必有编码cookie，Latin-1仅当注释或文档字符串涉及作者名字需要Latin-1时才被使用：

    另外使用\x转义字符是在字符串中包含非ASCII(non-ASCII)数据的首选方法。

    作为PEP 263实现代码的测试套件的部分文件是个例外。

导入

    通常应该在单独的行中导入(Imports)，例如：

No：import sys， os

Yes：import sys

        import os

   但是这样也是可以的：

    from types import StringType， ListType

    Imports 通常被放置在文件的顶部，仅在模块注释和文档字符串之后，在模块的全局变量和常量之前。Imports应该有顺序地成组安放：

1、标准库的导入(Imports )

    2、相关的主包(major package)的导入(即，所有的email包在随后导入)

    3、特定应用的导入(imports)

    你应该在每组导入之间放置一个空行，对于内部包的导入是不推荐使用相对导入的，对所有导入都要使用包的绝对路径。

    从一个包含类的模块中导入类时，通常可以写成这样：

        from MyClass import MyClass

        from foo.bar.YourClass import YourClass

    如果这样写导致了本地名字冲突，那么就这样写

        import MyClass

        import foo.bar.YourClass

    即使用"MyClass.MyClass"和"foo.bar.YourClass.YourClass"

表达式和语句中的空格

    Guido不喜欢在以下地方出现空格：

    紧挨着圆括号，方括号和花括号的，如："spam( ham[ 1 ]，{ eggs：2 } )"。要始终将它写成"spam(ham[1]，{eggs： 2})"。

    紧贴在逗号，分号或冒号前的，如：

      "if x == 4：print x，y：x，y = y，x"。要始终将它写成

      "if x == 4：print x，y：x，y = y，x"。

紧贴着函数调用的参数列表前开式括号(open parenthesis )的，如"spam (1)"。要始终将它写成"spam(1)"。

紧贴在索引或切片，开始的开式括号前的，如：

     "dict ['key'] = list [index]"。要始终将它写成"dict['key'] = list[index]"。

    在赋值(或其它)运算符周围的用于和其它并排的一个以上的空格，如：

#!Python

          x= 1

          y= 2

          long_variable = 3

要始终将它写成

#!Python

         x = 1

         y = 2

         long_variable = 3

    (不要对以上任意一条和他争论——Guido 养成这样的风格超过20年了。)

其它建议

    始终在这些二元运算符两边放置一个空格：赋值(=)， 比较(==，<，>，!=，<>，<=，      >=，in，not in，is，is not)，布尔运算 (and，or，not)。

    按你的看法在算术运算符周围插入空格。 始终保持二元运算符两边空格的一致。

    一些例子：

#!Python

          i = i+1

          submitted = submitted + 1

          x = x*2 - 1

          hypot2 = x*x + y*y

          c = (a+b) * (a-b)

          c = (a + b) * (a - b)

    不要在用于指定关键字参数或默认参数值的'='号周围使用空格，例如：

#!Python

          def complex(real， imag=0。0)：

              return magic(r=real， i=imag)

    不要将多条语句写在同一行上：

          No： if foo == 'blah'：do_blah_thing()

          Yes：if foo == 'blah'：

                   do_blah_thing()

          No：do_one()：do_two()：do_three()

          Yes： do_one()

               do_two()

               do_three()

注释

同代码不一致的注释比没注释更差。当代码修改时，始终优先更新注释!注释应该是完整的句子，如果注释是一个短语或句子，首字母应该大写，除非他是一个以小写字母开头的标识符(永远不要修改标识符的大小写)。

    如果注释很短，最好省略末尾的句号。注释块通常由一个或多个由完整句子构成的段落组成，每个句子应该以句号结尾。你应该在句末，句号后使用两个空格，以便使Emacs的断行和填充工作协调一致。

    用英语书写时，断词和空格是可用的。非英语国家的Python程序员：请用英语书写你的注释，除非你120%的确信这些代码不会被不懂你的语言的人阅读。

注释块

    注释块通常应用于跟随着一些(或者全部)代码并和这些代码有着相同的缩进层次。注释块中每行以‘#’和一个空格开始(除非他是注释内的缩进文本)。注释块内的段落以仅含单个‘#’的行分割。注释块上下方最好有一空行包围(或上方两行下方一行，对一个新函数定义段的注释)。

行内注释

    一个行内注释是和语句在同一行的注释，行内注释应该谨慎适用，行内注释应该至少用两个空格和语句分开，它们应该以'#'和单个空格开始。

        x = x+1                 # Increment x

    如果语意是很明了的，那么行内注释是不必要的，事实上是应该被移除的。不要这样写：

        x = x+1                 # Increment x

        x = x+1                 # Compensate for border

    但是有时，这样是有益的：

        x = x+1                 # Compensate for border

文档字符串

    应该一直遵守编写好的文档字符串的约定PEP 257 [3]。为所有公共模块，函数，类和方法编写文档字符串。文档字符串对非公开的方法不是必要的，但你应该有一个描述这个方法做什么的注释。这个注释应该在"def"这行后。

PEP 257 描述了好的文档字符串的约定。一定注意，多行文档字符串结尾的"""应该单独成行，例如：

      """Return a foobang

      Optional plotz says to frobnicate the bizbaz first。

      """

对单行的文档字符串，结尾的"""在同一行也可以。

版本注记

如果你要将RCS或CVS的杂项(crud)包含在你的源文件中，按如下做。

#!Python

        __version__ = "$Revision： 1。4 $"

        # $Source： E：/cvsroot/Python_doc/pep8。txt，v $

这个行应该包含在模块的文档字符串之后，所有代码之前，上下用一个空行分割。

命名约定

    Python库的命名约定有点混乱，所以我们将永远不能使之变得完全一致，不过还是有公认的命名规范的。新的模块和包(包括第三方的框架)必须符合这些标准，但对已有的库存在不同风格的，保持内部的一致性是首选的。

描述：命名风格

    有许多不同的命名风格。以下的有助于辨认正在使用的命名风格，独立于它们的作用。    以下的命名风格是众所周知的：

    b (单个小写字母)

    B (单个大写字母)

    Lowercase（小写）

    lower_case_with_underscores（有下划线的小写）

    UPPERCASE（大写）

    UPPER_CASE_WITH_UNDERSCORES（有下划线的大写）

    CapitalizedWords (或 CapWords，CamelCase这样命名是因为可从字母的大小写分出单词。这有时也被当作StudlyCaps。

    mixedCase (与CapitalizedWords的不同在于首字母小写!)

    Capitalized_Words_With_Underscores（有下划线的首字母大写） (丑陋!)

    还有用短的特别前缀将相关的名字聚合在一起的风格。这在Python中不常用，但是出于完整性要提一下，例如，os.stat()函数返回一个元组，他的元素传统上说名如st_mode， st_size，st_mtime等等。

    X11库的所有公开函数以X开头。(在Python中，这个风格通常认为是不必要的，因为属性和方法名以对象作前缀，而函数名以模块名作前缀。)

另外，以下用下划线作前导或结尾的特殊形式是被公认的(这些通常可以和任何习惯组合)：

_single_leading_underscore(单个下划线作前导)：弱的“内部使用(internal use)”标志。 (例如，“from M import *”不会导入以下划线开头的对象)。

single_trailing_underscore_(单个下划线结尾)： 用于避免与Python关键词的冲突，例如：“Tkinter.Toplevel(master，class_='ClassName')”。

    _double_leading_underscore(双下划线)：从Python 1.4起为类私有名。

    _double_leading_and_trailing_underscore_：“magic”对象或属性，存在于用户控制的(user-controlled)名字空间，例如：_init_， _import_ 或_file_。有时它们被用户定义用于触发某个魔法行为(例如：运算符重载)：有时被构造器插入，以便自己使用或为了调试。因此，在未来的版本中，构造器(松散得定义为Python解释器和标准库)可能打算建立自己的魔法属性列表，用户代码通常应该限制将这种约定作为己用。欲成为构造器的一部分的用户代码可以在下滑线中结合使用短前缀，例如：

_bobo_magic_attr__。

说明：命名约定

应避免的名字。永远不要用字符‘l’(小写字母el(就是读音，下同))，‘O’(大写字母oh)，或‘I’(大写字母eye)作为单字符的变量名。在某些字体中这些字符不能与数字1和0分辨。试着在使用‘l’时用‘L’代替。

模块名

    模块应该是不含下划线的，简短的，小写的名字。因为模块名被映射到文件名，有些文件系统大小写不敏感并且截短长名字，模块名被选为相当短是重要的，这在Unix上不是问题，但当代码传到Mac或Windows上就可能是个问题了。

 当用C或C++编写的扩展模块有一个伴随Python模块提供高层(例如进一步的面向对象)接口时，C/C++模块有下划线前导(如：_socket)。Python包应该是不含下划线的，简短的，全小写的名字。

类名

几乎不出意料，类名使用CapWords约定。内部使用的类外加一个前导下划线。

异常名

如果模块对所有情况定义了单个异常，它通常被叫做“error”或“Error”。似乎内建(扩展)的模块使用“error”(例如：os.error)，而Python模块通常用“Error” (例如：xdrlib.Error)。趋势似乎是倾向使用CapWords异常名。

全局变量名

(让我们祈祷这些变量仅在一个模块的内部有意义)

    这些约定和在函数中的一样。模块是被设计为通过“from M import *”来使用的，必须用一个下划线作全局变量(及内部函数和类)的前缀防止其被导出(exporting)。

函数名

函数名应该为小写，可能用下划线风格单词以增加可读性。mixedCase仅被允许用于这种风格已经占优势的上下文(如：threading.py)，以便保持向后兼容。

方法名和实例变量

这段大体上和函数相同：通常使用小写单词，必要时用下划线分隔增加可读性。仅为不打算作为类的公共界面的内部方法和实例使用一个前导下划线，Python不强制要求这样：它取决于程序员是否遵守这个约定。

使用两个前导下划线以表示类私有的名字，Python将这些名字和类名连接在一起：

如果类Foo有一个属性名为_a，它不能以Foo._a访问。(固执的用户还是可以通过Foo._Foo__a得到访问权。)

通常双前导下划线仅被用于避免含子类的类中的属性名的名字冲突。

继承的设计

始终要确定一个类中的方法和实例变量是否要被公开。通常，永远不要将数据变量公开，除非你实现的本质上只是记录，人们几乎总是更喜欢代之给出一个函数作为类的界面(Python 2.2 的一些开发者在这点上做得非常漂亮)。

同样，确定你的属性是否应为私有的。私有和非私有的区别在于模板将永远不会对原有的类(导出类)有效，而后者可以。你应该在大脑中就用继承设计好了你的类，私有属性必须有两个前导下划线，无后置下划线，非公有属性必须有一个前导下划线，无后置下划线，公共属性没有前导和后置下划线，除非它们与保留字冲突，在此情况下，单个后置下划线比前置或混乱的拼写要好，例如：class_优于klass。

最后一点有些争议：如果相比class_你更喜欢klass，那么这只是一致性问题。

设计建议

单个元素(singletons)的比较，如None 应该永远用：‘is’或‘is not’来做。当你本意是“if x is not None”时，对写成“if x”要小心。例如当你测试一个默认为None的变量或参数是否被设置为其它值时，这个值也许在布尔上下文(Boolean context)中是false！

基于类的异常总是好过基于字符串的异常。模块和包应该定义它们自己的域内特定的基异常类，基类应该是内建的Exception类的子类。还始终包含一个类的文档字符串。例如：

#!Python

        class MessageError(Exception)：

            """Base class for errors in the email package。"""

使用字符串方法(methods)代替字符串模块，除非必须向后兼容Python 2.0以前的版本。字符串方法总是非常快，而且和unicode字符串共用同样的API(应用程序接口)在检查前缀或后缀时避免对字符串进行切片。用startswith()和endswith()代替，因为它们是明确的并且错误更少。例如：

        No： if foo[：3] == 'bar'：

        Yes： if foo。startswith('bar')：

例外是如果你的代码必须工作在Python 1.5.2 (但是我们希望它不会发生！)，对象类型的比较应该始终用isinstance()代替直接比较类型，例如：

        No： if type(obj) is type(1)：

        Yes： if isinstance(obj， int)：

检查一个对象是否是字符串时，紧记它也可能是unicode字符串！在Python 2.3，str和unicode有公共的基类，basestring，所以你可以这样做：

        if isinstance(obj， basestring)：

在Python 2.2类型模块为此定义了StringTypes类型，例如：

#!Python

        from types import StringTypes

        if isinstance(obj， StringTypes)：

在Python 2.0和2.1，你应该这样做：

#!Python

        from types import StringType， UnicodeType

        if isinstance(obj， StringType) or \

           isinstance(obj， UnicodeType) ：

对序列，(字符串，列表，元组)，使用空列表是false这个事实，因此“if not seq”或“if seq”比“if len(seq)”或“if not len(seq)”好。书写字符串文字时不要依赖于有意义的后置空格。这种后置空格在视觉上是不可辨别的，并且有些编辑器(特别是近来，reindent.py)会将它们修整掉。不要用==来比较布尔型的值以确定是True或False(布尔型是Pythn 2.3中新增的)

        No： if greeting == True：

        Yes： if greeting：

        No： if greeting == True：

        Yes： if greeting：

http://net.pku.edu.cn/%7Eyhf/tao_regexps_zh.html

python这种编程语言我很早就听说它了，早在1998年，我在玩Linux的时候，就接触过它，但是我对python的印象仅仅停留在它是一种流行的面向对象的脚本语言的认识上。

zope，基于python的app server，早在2000年我就已经对它如雷贯耳了，但是我对zope的印象仅仅停留在它是一种类似Apache HTTPD Server，AOL Server之类的web server上。

今年ozzzzzz多次向我提到python和zope，听得我耳朵都起了老茧了，dlee又建议我开设python版面，虽然我没有答应，但是架不住朋友们的左劝右劝，终究对python这门语言有了好奇心。

几天前，当我漫不经心的浏览了python和zope的网站之后，我突然有了一种“众里寻它千百度，那人却在灯火阑珊处”的感觉，悔不迭错过了那么多次相逢的机会。

对于软件开发，我和ozzzzzz有一个共识，就是脚本解释弱类型语言在开发效率上远远超过编译强类型语言，从软件开发角度来说，脚本语言具备天然的开发效率上的优势，这是由语言的内在属性决定的。

例如我们可以比较一下Web编程使用PHP和Servlet/JSP，比较一下Windows桌面应用使用VB和VC/Delphi，比较一下Unix环境下面Shell和C/Java，比较一下数据库环境下面的PL/SQL和JDBC/SQLJ。

我虽然使用Java开发软件已经有5年的历史了，但是能不用Java的时候，我一定不会用Java的。如果搭建一个小型的网站，我一定选择PHP而不是Java；如果针对数据库的小型编程，我一定使用PL/SQL而不是Java；如果是桌面应用，我一定选择VB而不是Java；如果是Unix环境我宁愿选择shell，perl甚至PHP，而不是Java。

做为一种严谨的，编译式的，面向对象语言，Java总是给我一种须正襟危坐，须一板一眼的按照OOAD的原则编程，才敢在键盘上敲下字符的感觉。即使编写一个最小规模的程序，我也不能够接受把所有的code塞到main里面的做法。Java似乎以不怒自威的威严使我不敢随意编码，不敢玷污Java的严谨。于是我即使写一个很简单的JDBC程序，也要一板一眼的try catch finally，一层层的处理Connection，PreparedStatement和ResultSet。

诚然，如果开发规模比较大的项目，或者开发自有的软件产品，必须应该按照严谨的方式，此时Java也是最适合的语言。但是我不想活的那么累，很多人也不想活的那么累，于是大家都怀念起来脚本语言的好来。对于小规模的应用，使用脚本语言快速简单完成的事情，当你使用Java的时候，你陷入了过多的层层代码包围中去。于是groovy出现了，bean shell出现了。大家终于明白，编译语言不是软件开发的全部，脚本语言才是最适合程序员的语言。

我喜欢脚本语言，喜欢的没边，Java是我的职业，但是我从来都没有在内心深处喜欢过它的语法，我更加讨厌C++变本加厉的复杂。我钟爱的语言包括小学就接触的BASIC和Logo，毕业以后才掌握的Unix Shell和PHP，Perl，PL/SQL。几乎我接触过的每种脚本语言，我都有浓厚的兴趣和感情，除了VBA是一个例外。

看看Java里面长长的对象，方法和属性命名，看看Java编程冗长的调用语句和愚蠢的对象赋值和经常长达几十行的getter/setter，我会时不时从心底泛起恶心的感觉，虽然我经常也是这种恶心感觉的制造者。但是恶心归恶心，我知道Java有它不可取代的作用，PHP有它无法弥补的缺陷。大部分脚本语言，包括perl，PHP，PL/SQL，VBA都不是真正意义上的面向对象编程语言，即使包括了部分面向对象语言的特性，这注定了脚本语言不能够承担大型项目的开发，甚至也不能够充当良好的可复用的组件存在。

所以我很遗憾，我欣赏PHP脚本语言的开发效率，我也欣赏Java的面向对象的能力，我欣赏PHP的低部署成本高可靠运行，我也欣赏Java App Server带来的开发复杂运算的强大能力，但是鱼与熊掌不可得兼。

直到我看到了python和zope，我终于找到了梦寐以求的东西，兼有脚本语言开发的高效率，兼有低部署成本的易用性，同时又有完备的面向对象的强大支撑能力，同时又具备完善的强大的app server支持。最令我生气的还是plone，这个运行在zope之上的软件，你可以称之为portal，或者称之为cms，或者其他的什么名词，但是我知道它几乎可以实现任何网站想要实现的功能。默认安装下，这个东西很像confluence，一个Java的商业的cms，但是比confluence功能强大的太多，可定制性，可开发性又强的太多了。plone在默认安装情况下你就可以把它当做cms来用，比较类似***nuke类软件(PHPNuke, PostNuke, JBossNuke,...)，通过插件的扩展，你可以让plone里面集成了forum，blog，wiki的功能，再加上plone本来就支持的WebDAV，功能强大的基于文档的权限控制，多用户多组的管理，你可以在很短的时间内实现一个全功能的门户网站。可笑的是，我从去年到今年一直在考虑把JavaEye建设成为一个集成forum，blog，wiki，cms功能的网站，甚至雄心壮志的想要做一个这么的软件产品来，但是现在我发现plone已经漂亮的实现了这一切，最令我沮丧的是，ozzzzzz在听过我的软件产品计划之后提出一个用关键词来组织网站内容的设想，结果我发现plone已经这样做了，我能说的只有惭愧！

我只能感叹自己没有在一年之前就发现plone，否则的话现在的JavaEye将完整的使用plone来架设。更令我惭愧的是，当我刚刚意识到zope/plone的价值的时候，上海已经有人成立了专业的zope/plone解决方案的软件厂商，并且拿下了好几个大型的客户，(http://www.zopechina.com)。有时候我们真的不能把眼睛盲目的盯着大厂商强行推广的标准了，应该好好的审视自己真正需要的是什么，并且围绕它构建自己的核心竞争力，否则我们只有永远做IT行业食物链最底层的命运。

ozzzzzz曾经对我说，zope是B/S应用中的VB，快速原型开发中小型企业应用的最佳武器，我现在真切的理解了他的话。我觉得我们确实不能够眼睛光盯着Java/C#不放，也应该了解一下zope/plone，它应该成为中小型企业应用，特别是基于文档管理的企业应用的最重要的解决方案。

zope/plone虽然很好，但是我知道它不会如Java/J2EE，C#/dotnet那样在国内成为一种主流的软件开发解决方案。原因就在于国内的软件开发行业长期处于国际分工产业链的底层，缺乏创新意识和开拓的精神，而往往满足于跟随跨国公司的标准，啃啃人家剩下的肉骨头。位于食物链顶层的厂商，例如MS，IBM，Sun，BEA，CA，Oracle等等，争夺的是标准。他们是规则的制订者，制订好了规则，放大家进场，他们负责收费，钱收的差不多了的时候，他们又重新竞争，制订新一轮的规则，继续坐地收费。很多时候，市场的真实需求并没有被真实的体现，真实的需求被顶级厂商掩盖了。他们创造了一个市场需求，有了市场需求，就有钱赚，赚的差不多了，就摧毁这个市场，然后创造下一个市场需求。因此本质上来说，IT行业就是几个寡头在博弈，不管谁赢谁输，我们都是输家，我们只是人家的筹码。大家可以回顾一下这些年软件技术发展的历程，寡头厂商制造了EJB市场赚大发了，寡头厂商了制造了ERP市场赚大发了，寡头厂商继续在制造着SOA，等着继续收钱。我们不能够被满天飞的技术迷惑了，我们不能被人卖了还替人家数钱。

所以多多关注一下我们真正需要的技术吧。