成员面对面: Brett Cannon

原文链接: Meet the Team: Brett Cannon

"成员面对面(Meet the Team)"是一系列简单介绍Python核心开发组的成员的文章, 本帖 是该系列中的一篇.

姓名:	Brett Cannon
地址:	美国，加利福尼亚州,旧金山
主页:	https://profiles.google.com/bcannon
博客:	http://sayspy.blogspot.com

你使用Python多久了?

从2000年秋天开始.

你成为Python核心代码提交者多久了?

从2003年4月开始(就在PyCon 2003大会之后)

你是从什么时候开始成为核心开发者的? 你还记得第一次commit吗?

我成为一个核心开发者,是因为我经常麻烦别人帮我提交补丁(这个技巧已不像以前 那么有用了).从2002年8月我开始复兴Python-Dev的总结报告.(持续了将近2.5年). 在写这些总结时,我经常发现一些小问题,就顺手解决他们.由于我经常在python-dev 上交流,我就让那些同伴检查下我的补丁并帮我提交.有一天Guido问我为什么不自己 提交,我就回答说我没有相关的提交权限,然后他就差不多说了句"你现在有了".

我的第一次commit(changeset 28686),是用来修复time.strptime()函数中的 字符串转义问题(这是我对Python本身的第一次贡献).

你现在负责Python的那一部分?

我主要关注import机制,还负责使Python语言能够在所有的虚拟机上顺利运行.

除了核心开发工作以外, 你还在那些方面用到Python?

我设法在我的博士学位论文中只使用了点Python,主要是用Python实现服务端的一些 东西.在其他情况下,我所有的私人项目都尽可能的使用Python.并且我未来在Google 公司的工作也主要使用Python.

除了编程以外, 你还做些什么?

我是一个电影爱好者,也会选择性的看一些电视(在2000年夏季的高温中失去了 我的电视对我来说是一件意外的好事;而和我的妻子结婚是我有意为之所做的最好 的事情 =). 在其他时间,我经常做做阅读,主要是看看杂志和一些网站,还有好些 一直在看而没看完的书.

Windows 的 Python 加载器

原文链接：A Python Launcher For Windows

Mark Hammond （ pywin32 的作者以及 Windows 版 Python 的长期支持者）写了 PEP 397，描述了 Windows 下的一个新的 Python 加载器。Vinay Sanjip （ logging 模组的作者）最近实现了这个加载器，下载地址是 https://bitbucket.org/vinay.sajip/pylauncher/downloads

该加载器为 Windows 下的 Python 脚本（.py 和 .pyw 文件）提供了选择 Python 版本的功能，从而可以方便地同时使用 Python 2 和 Python 3 两个版本。

Windows 用户可以试着下载并且测试一下这个加载器，帮助 Python 开发人员解决掉剩下的问题。该加载器是以独立应用程序打包的，而且会支持目前可用的所有版本的 Python。我们的目标是一旦有了加载器的最终版，我们就将其集成到 Python 3.3 中，当然我们还会为其他版本的 Python 提供这个加载器的独立安装包。

这个加载器有两个版本，launcher.msi 会将文件安装到 Program Files 目录下，而 launchsys.msi 会将其安装到 Windows 的 System32 文件夹下。我们还为 64 位 Windows 提供了 64 位的安装包。

加载器的一些细节

PEP 397 中有对该加载器的行为的完整说明。简单概括有如下几点：

• 该加载器提供了两个可执行文件——命令行版本的 py.exe 以及 GUI 版的 pyw.exe。
• 加载器将被注册为 .py 和 .pyw 文件的默认处理工具。
• 当执行脚本时，加载器会从脚本中寻找 Unix 式样的含 #! (shebang) 的一行，它会识别出 python （系统默认的 Python 版本）、python2 （默认的 Python 2 发行版）、``python3`` （默认的 Python 3 发行版）这几个字样。你还可以为不一样的计算机和不一样的用户定制不同的加载行为。
• 单独执行 py.exe 命令会调出 Python 的交互式解释器。py.exe 提供命令行参数支持，py -2 会加载 Python 2，py -3 会加载 Python 3，而 py 则会加载系统默认的 Python 版本。

简单的使用说明

安装以后，加载器会将自己与 .py 和 .pyw 文件关联起来。除非你特别干预，脚本在运行时还是会使用默认的 Python 版本，所以你实际使用时将看不到任何变化。如果你经常使用命令行的话，你可以考虑将 .py 添加到你的 PATHEXT 环境变量中，这样你的脚本就不会在独立的命令控制台执行了。

如果要指定脚本使用 Python 2 编译器，只要将脚本的第一行写成如下格式就可以了：

#!/usr/bin/env python2

这样写和 Unix 是兼容的。如果你不需要兼容 Unix，写成 #!python2 也可以。

如果你想要指定脚本使用 Python 3，那你需要为脚本添加：

#!/usr/bin/env python3

你还可以使用下面这些命令启动 Python 解释器：

# Default version of Python
py
# Python 2
py -2
# Python 3
py -3

前提是你已经将 py.exe 加入了你的路径设置。launchsys 版的加载器会为你自动做这个设置，不过 launcher.msi 的安装目录(C:\Program Files\Python Launcher) 需要被手动加到路径中。

进一步阅读

下面的几个 python-dev 邮件组的讨论内容包含了一些关键的内容：

• Mark 宣布 PEP 初稿发布: http://mail.python.org/pipermail/python-dev/2011-March/109509.html
• 该 PEP 的第二版草稿发布: http://mail.python.org/pipermail/python-dev/2011-March/109786.html
• 最初 Vinay 关于用 C 实现加载器的询问: http://mail.python.org/pipermail/python-dev/2011-June/112145.html
• Vinay 宣布 C 语言实现的完成: http://mail.python.org/pipermail/python-dev/2011-July/112184.html
• Vinay 的测试号召帖: http://mail.python.org/pipermail/python-dev/2011-July/112251.html

CPython 3.2.1 发布

原文链接：CPython 3.2.1 Released

Python 核心开发组的 Release Manager Georg Brandl 代表 python-dev 团队宣布： CPython 3.2.1 正式发布了。Windows 安装包和 tarball 包在 7 月 10 日已经发布，各位可以考虑升级到这个版本了。

What's New 中列出了 3.2 版中的新增内容，Misc/NEWS 中列出了我们修正了的所有 bug。

如果你在该发行版或者别的发行版中发现了问题，请报告至http://bugs.python.org/。

Python 3.2.1 RC2 发布

原文链接：3.2.1 Release Candidate 2 Released

紧跟着六月的新版发布高峰期，Python 3.2.1 的第二个候选发行版已经发布了。自从 5 月 15 日第一个候选发行版发布以来，我们已经修正了 40 多个问题。我们期望大家在自己的项目里测试一下这个候选版，这也是 3.2.1 最终发布前的最后检查了。

修正了哪些问题？

I/O

问题 #1195 已经呆在那里若干年没人碰过了，不过在这个 RC 版里，我们在调用 fgets 前添加了一个简单的清除错误的动作，这就解决了在 input() 中 CTRL-D 会中断 sys.stdin.read() 的问题。另外我们针对问题 #12175 的 readall 方法做了清理，让它在 read() 返回 None 的时候也返回 None，而在无法打开文件时抛出 ValueError。

另外我们解决了 #11272 中 Windows 系统下 input() 尾随 \r 的问题，虽然这不是 RC2 新加的内容，这也是对 Windows 下是 input() 的重要修正。这个问题已经被报告很多次，而且影响了很多人（有没有人想起 distutils 的 upload 命令了呢？），所以我们希望 3.2.1 为你解决了这个问题。

Windows

3.2.0 为 Windows 带来一个新功能，也就是 os.symlink 的支持。随之而来的就是 #12084， os.stat 检查 Windows 符号链接（symlink）时的问题。所以这次我们修正了多个 stat 函数的内部代码，以解决这个问题。

有一名用户发现 os.path.isdir 的速度很慢，尤其是检查 symlink 的速度比检查正常文件慢一倍，他而且发现和函数依赖 os.stat 有关。虽然 os.path.isdir 不可能是大家的性能瓶颈，但在解释器启动时会被调用很多次，所以在 #11583 里边我们改用了 GetFileAttributes，从而略微提升一下启动的速度。

subprocess 模块

过去如果给了 Popen 一个错误的参数会导致 AttributeError，这个问题是在 #12085 中提交的，而提交者也提供了解决方案。由于 3.2.0 中的一处更改，导致 Popen 无法正确处理空环境变量，具体也就是 env 这个参数。#12383 就是这个问题的报告，而且这个问题提交后就立即被修正了。

更多的更新！

你可以查看完整的 3.2.1 RC2 更新记录，你也可以现在就下载该版本的 Python！

一如既往，请将你发现的问题提交至 http://bugs.python.org 。有了大家的帮助，我们就可以保证新版的质量，谢谢大家。

2011 年 6 月 Python 新版发布情况

原文链接： June Releases - 2.6.7, 2.7.2, 3.1.4

六月是 Python 新版发布的重要月份，所有的活跃分支都有更新。

2.6.7

新版的 Python 2.6.7 已经发布。该版本是 source-only，也就只发布源代码的版本，该版本的更新修正了三个安全问题。现在 2.6 系列已经进入了 security-mode，后续的更新将仅针对安全问题在必要时发布，而且发布内容将只包含源代码，直至2013年10月2.6分支生命终结为止。如果你需要二进制安装包，你应该考虑升级到 2.7 或者 3.2。

2.6.7 包含针对此前提到过的 urllib 漏洞的首次修正。此外 2.6.7 还修正了两个问题，分别是 smtpd 的 DoS 漏洞(Issue #9129)和 SimpleHTTPServer.list_directory 的 XSS 漏洞(Issue #11442)。

2.7.2

2.7 版是 2.x 系列的最后一个版本。自从 2010 年 11 月 2.7.1 版发布以来，到现在收录了150 多个 bug 修正。2.7.2 版的源代码和二进制安装包已经在 6 月 12 日发布，其中包含了 2.6.7 版中的漏洞修正。

2.7.2 还修正了不少的程序崩溃：其中一种情况是 Python 使用了非 Python 管理的内存，当该内存区域在别的线程中被访问到时，Python 就会发生崩溃。另外一种情况在从类中删除__abstractmethods__ 时发生。还有一种情况是访问内存映射文件时，读取范围超过了文件长度。此外还有一些别的情况，这里就不一一举出了。

我们在 getpass 里修正了一处关于 CTRL-C 和 CTRL-Z 处理的回归错误。multiprocessing 也修正了一些错误，包括将 Windows 服务当作冻结的可执行文件的错误，终结 multiprocessing.Pool 的 worker 时的竞争状态错误。mmap在修正后将可以处理大于 4 GB 的文件（即使在 32 位发行版中也支持），而且在试图向不可写的map 写入时将抛出 TypeError，而不是以前的 segfault 了。

如果你想查看完整的更新记录，请参见 the 2.7.2 news file。

3.1.4

3.1.4 是 3.1.x 分支的最后一次 bug-fix 发行版，此后 3.1 系列将进入 security-mode。而 3.2 分支将继续开发下去。3.1.4 包含了 2010 年 11 月 3.1.3 发布以来的超过 100 个 bug 修正。和 2.7.2 一样，我们在 6 月 12 日发布了二进制安装包，而且 3.1.4 也包含了 2.6.7 中提到的安全问题的修正。

3.1.4 还修正了一些别的问题：对 object 进行 __dir__ 查询时的问题。Windows 下os.stat 和 os.utime 在超过 2038 年后出现的问题。针对 64 位版本代码的清理。io 库中也有一些修改，在未读取任何东西时将返回 None，在其它的位置也会raise 正确的 exception。ctypes 库修正了在 64 位 Windows 上面的 callback 参数，另外还修正了一处崩溃。

如果你想查看完整的更新记录，请参见 the 3.1.4 news file。

3.2.1

3.2.1 目前还处于 RC 阶段，其中第一轮的 RC 已经发布过了，第二轮的 RC 也会在近期发布。我们期望 3.2 的用户多多试用这些 RC 版，这样我们就能及时解决你看到的问题。如果你想要报告 bug，请通过 bugs.python.org 提交给我们。

2011Python语言峰会报告

原文链接： 2011 Language Summit Report

今年的语言峰会于c3月10号星期四在亚特兰大举行，正好是PyCon会议部分开始的前一天。 到场的有 CPython, PyPy, Jython, IronPython 和 Parrot VMs 的成员; 来自 Fedora, Ubuntu, 和 Debian 的包开发者; Twisted 项目的开发者，以及 其他一些人。

开发博客

第一条讨论事宜就是由PSF交流主任Doug Hellmann提出的博客（也就是本博客的英文主站)。 由于python-dev邮件列表内容多且讨论激烈，博客将成为用户获取开发新闻的简易通道。 我们计划博客内容涵盖PEP，所有的大决策，新的特性，以及严重的漏洞修复，以及一些关于 开发进程的非正式报道。

所有Python实现都可以在该博客上发表博文。比如，尽管PyPy已经有了 他们自己活跃的博客 ， 仍然欢迎他们把新闻同时发布到这儿。关于其他实现的相关讨论也已经在 python.org download page 中提到。他们的发行也会作为新条目列在 python.org 首页上。

兼容性警告

在3.2版的Python里，我們引进了ResourceWarning來帮助使用者找到依赖CPython引用计数 (reference counting)的代码段。这个警告不只是要帮助使用者写出更好的代码， 更可以 让使用者写出更安全的跨VM运行的代码，为了更进一步強化各种VM之间的兼容性， 我們提 出了一种新的警告类型: CompatibilityWarning.

這隔想法会被提出是起源于一个被PyPy开发者所发现的CPython Bug。 Issue #11455 解释了CPython 允许使用者可以自定义出 __dict__ 的key不为字符串的类型。 而PyPy 及Jython 目前并不支持这种做法。理想情况下，使用者可以开启警告來发现这种 情况，就如同使用ResourceWarning的作法一样。

独立的标准模块库

在CPython从Subversion转移到了Mercurial之后，把Python的标准模块库抽离开來单独维护 的想法又被提了出來。其他Python实现的开发者对这转变非常感兴趣，因为这可以大大的 简化他们现在的工作流程。现在的流程会抽出CPython某一個时间点的标准模块库的快照， 为这些模块库加上些与他们实现相关的patch，再把C的extension换成完全使用Python写的版本， 等等其他类似的做法。

需要把这样的转变写入在以后的PEP(Python Enhancement Proposal)里。其中有个论点提及 该如何确定版本。由于标准模块库会独立于各种Python实现方式之外，所以很可能会有它 自已独立的版本，这之后的测试就要把版本加入到考虑范围之内了。

另一个关于标准模块库的话题是关于那些同時有Python实现和C语言扩展实现的模块。 PyPy中的一位成员，Maciej Fijalkowski提到随着时间的演进，一些模块的C和Pyhon版本 之间的差别已经很小了。既然打算把标准模块库独立出去，他们建议这些模块的改动需要 更严格一点，以免偏袒其中任意一种实现方式。此外，大家决定偏向于纯Python实现，c语言版 的模块只有在大大提高了性能时才会被创建。

性能测试站点

PyPy竞速场(PyPy Speed Center)很清楚的展示了PyPy的性能強大。所以开始讨论python.org 也可以有一個类似的网站。比如像是performance.python.org这种名字。而且也会评估其他 各种Python实现的性能。除了性能之外，内存的使用量，语言的兼容性也应该展示出來。 这将会花费不少功夫在改变这个架构以使它能测试各种Python 实现，现在它只会比较PyPy跟CPython。

在 奧瑞冈州(Oregon)大学Open Source实验室 工作的Allison Randa 将会负责这些性能测试。但测试需要很多高性能的主机，Jesse Noller欢迎大家捐赠机器。 有兴趣的朋友，请联系 Python Software Foundation 并且查看下我们的 捐赠页面 。

解除束縛

从CPython 3.3的开发開始，我們不再冻结语言本身的变化。尽管水库的闸门已经打开了， 我们会放慢改变的速度，保守的修改语言，以期让其它语言的实现可以赶上进度。 虽然没有一个赶上3.x的进度，目前PyPy以及IronPython已经是2.7兼容了，并且IronPython 已经准备向Python 3.x兼容进发。

3.3预期会接纳 PEP 380 ，这个PEP 引入了新的语法， yield from <expr> ，让generator可以 yield 到另一个generator。 除此之外，Python语言近期內不會有改变。

异常的属性

下一个讨论的主题是让异常(exception)提供更有意义的属性，而不是让使用者仅只靠字符串 信息。 比如说，当遇到ImportError时，以往要通过解析寻找才能知道是哪个模块import 失败了。如果可以直接知道是什么模块import时发生了错误才是有用的做法。

这种实现方式只能依赖于使用关键字（keyword）参数來初使化异常对象。目前已经有现成 的 ImportError补丁 可以參考。

开发者协议

我們也提到了开发者协议(Contributor Agreements), 目前已有了大概的雏形。 其中一个 启发我们的是Google的 个人开发者协议 。 这个议题已经被讨论了很久，很多人很期待可以明确的制定这个协议。除此之外，我们也 会确保在美国之外，这个协议也可以保持效用。

Google Summer of Code

Martin von Löwis 花了一分种介绍了今年的Google Summer of Code，开发者不仅可以扮演导师， 更可以提出想做的项目來让学生完成。 而且提出项目的人也不一定要指导学生。如果你有 兴趣帮忙的化，请看PSF的 寻求项目与导师 。

Distutils

Distutils2 即将完成，Tarek Ziadé 提到他们下一个目标是完成Python 3的移植以及最终 合并回标准模块库。除此之外，合并后将會改用一个新名字， packaging, 这个packaging 团队还是计划提供独立的仍叫做Distutils2的包，来继续支持Python 2.4 到 3.2。

这个项目目前非常成功，当前的结果在 Bitbucket ， 且正在等待合并到标准模块库中。

其实VM实现的未来

IronPython提及了他们的未來计划，他们将会立即着手3.x版的开发。他们在PyCon上发布了2.7 版。 2.7版是他們第一个基于社区的版本，自从这个项目从微软脱手之后。而且在这几个月內会往3.x版前进。

Jython 最近才刚发布2.5.2版，而且开始计划2.6版。由于2.6版和2.7版的差別不大，一些人 提议跳过2.6版，直接开发2.7版。但是这么做的话，新版本的发布需要更多的时间。基于 ”早点发布，频繁发布“的口号，Jython不太可能从2.6跳到3.x版。而会稳定地开发2.6版及2.7版。

开发赞助

赞助开发工作可以让那些不同的Python实现加速他們到兼容3.x的开发。当有赞助后， 请把计划提到PSF，才有机会可以使用那些赞助。那些有兴趣接受赞助的团体，请联络PSF。

基本款的Python

Jim Fulton开始讨论到他称之为基本款(baseline)的Python。凭他在部署Python应用的经验， 有太多不可預期的状况发生。由于有Ubuntu/Debian的packaging专家在场，我们得以知道问题 的根本原因。

以Fedora上所安裝的Python 的情况的来说，Python以Live CD可以正常运行为目标，所以 只安装非常小的部份。 目录结构的位置也有所不同，比如手有一些标准模块从标准模块库 之中移除了(像是distutils)，或是有一些库的版本是过期的旧版本。

这个问题还沒有明确的解法，但相关的人士已经在着手处理这个问题。

3.3新特性

提到了3.3的新特性。包含了2个PEP。 PEP 382 ， 包含了命名空间的包。讨论该怎么和distutils整合时也提到了这一点。

PEP 393 ，定义了一个灵活的字符串表示。 它也吸引了一些学生想在GSoC参与这个项目。不过除了考虑实现，内部实现还要考虑性能及内存使用， 才有可能最终被接受。

Unladen Swallow

Unladen Swallow当前处于"停工"状态，也不会包含在CPython 3.3之中。为了让这个计划 可以有所进展， 并且由于目前这方面的专家还无法开始做这项任务，我们需要更多有能力的人 来加入这个计划。在讨论中也提到可能需要资金才能将Unladen Swallow的品质提升到更高 的层次，请有兴趣的组织联系PSF。

虽然Unladen Swallow正在停工中且不确定未來走向，这个计划还是对Python及其他一些 开源项目产生了贡献，比如Unladen Swallow的性能测试对测试其他Python实现的性能很有帮助。 Unladen Swallow的开发者对LLVM及Clang也提供了很多的贡献。

Two other performance ideas were also briefly discussed, including Dave Malcolm's function inlining proposal. Martin von L?wis mentioned a JIT extension module he has in the works, although the PyPy developers expressed skepticism of the effectiveness of a JIT of this kind. 別的性能提升的想法也简明地提及了，包括Dave Malcolm函数内嵌的想法。Martin von Löwis 提到了他正在著手的即时变异(JIT)扩展模块，尽管PyPy的开发者对这种做法的效率持怀疑态度。

向异步框架铺设路径

今天的最后一项讨论是把Twisted整合进标准模块库。主要的想法是要有一個类似asyncore 的模块，可以让Twisted或其它的异步框架可以较容易得整合进來。

这个过程也会被写进PEP里面，一些人建议可以把这个PEP写得像WSGI一样，但是目标是针对 异步事件。除了这篇PEP的作者之外，Twisted项目以及其他相关人员都需要花费心力一起完成 这个提议。

更多资讯

想知道更多的资讯的话，请看CPython的开发者Nick Coghlan的 rough notes 和 highlights 。

Python2.7与3.x版本之间的不推荐用法

原文链接： Deprecations between Python 2.7 and 3.x

最近 在python-dev上的讨论 指出了从Python2.7转移到当前Python3.x版本的开发者面临的Python当前的deprecation方针问题。 由此，并鉴于Python用户一般会直接从Python2.7转移到最新的3.x版本而不关心期间的旧版本， 开发团队修改了当前的deprecation方针。

背景

Python承诺向后兼容。不符合兼容性准则的改变时不允许发生的，这意味着当前正确的程序 不会在新版本中崩溃。然而，这并不总是可行的，比如，当有些API已经明显失效了，并即将 被其他替换调时。在这种情况下，Python遵循deprecation方针：当某项特性被正式移除之前 有一段长达1年的转换期。在这中间过程中，必须发布deprecation警告使开发者有时间更新他们 的代码。Python的deprecation方针的详细内容在 PEP 5 文档中。鉴于改变只会在新 的Python发行版中出现，而且新旧发行版之间一般有18个月的间隔，这就意味着一次发布的 deprecaton间隔刚好时标准。

这个方针的唯一例外时Python 3。Python 2到Python 3之间的大版本改变主要是为了允许 破坏向后兼容性的改变也能发生，是Python开发者能够解决当前方针下不能解决的问题。 比如，让字符串支持Unicode，以及返回迭代器而不是列表。

并行开发

大家都清楚转换到Python 3需要一些时间，很多人估计大概为5年。所以Python 2和3会并行开发 一段时间。

Python 2.7作为Python 2的最后一个发行版，大家都同意把它的维护时间大大延长。最终， 要迁移到更新版本的开发者会跳到Python 3版本。

下面就是其中一个问题...

令人吃惊的deprecation

在 python-dev上的帖子 中, 有人 指出在C API中的一个函数 PyCObject_AsVoidPtr, 和它带有的不充分的警告一起移除了。 但是，这是与deprecation方针相违背的！到底发生了什么？

这个改变是一个从旧API（``PyCObject``)迁移到新的，改进的(PyCapsule)过程中 的一部分。问题时 PyCObject 是Python2.6中默认且仅有的API。它在Python2.7中已经不推荐了。 在Python3.2中，那API根本不存在，所以新的 PyCapsule 应该被使用。那就有了一个 deprecation间期，从Python2.7的发布（2010年7月）到Python3.2的发布（2011年2月）—— 大约7个月。这远远小于最少12个月的间隔要求，是开发者很难支持所有的Python发行版。

对于从3.0升到3.1然后3.2的人来说，这个deprecation路径没什么问题。Python3.1在2010年 3月发布时就已经有这个deprecation，因此3.x 系列的版本都有这个deprecation，12个月的 deprecation间隔要求是满足的。然而，那并不是实际人们所做的：他们直接从Python2.7升到了 最新的3.x版本，在当期例子里时3.2，产生了这个问题。这不是python-dev的初衷，不幸的是PEP 5 并没有对同时处于积极开发的并行版本做出说明。

那么我们该怎么做？

尽管 PyCObject/PyCapsule API断线是一个明显的问题，这并不是无法解决的问题， 虽然python-dev中有人还是碰到了很多麻烦。总而言之，这问题不应该发生。

PyCObject/PyCapsule 这个特例问题已经存在，我们无法对它做什么。重新启用 PyCObject 不是一个明智之举，因为这样只会增加未来的不兼容性。然而，大众意见表明， 虽然有点繁琐，写一些多余的适配代码来使用当前可用的API，还是可行的。实际上，在Python3.1, PyCObject API是写成 PyCapsule API的封装形式的。有人建议，如果有人需要使用这API的话， Python3.1的实现可以分离成第三方库的形式。此外，大家一致同意，写一个包含这个改变的“反向” PEP，来解释这个改变背后的原因，以及帮助开发者迁移的文档资料。

作为更一般的提醒，Python开发团队现在意识到了这个问题，并开始避免它再次发生。 Guido对情况 发表了总结 并建议Python 3目前对使用deprecation尽量采取保守的态度。至少，不推荐的API在移除前 保留更长的时间，给使用Python 2.7的开发者一条顺利的迁移路径。

更间接地，这个帖子提出话题告诉大家如何在很短时间内更有效的将Python中的更改信息告诉广大的用户， ——这个也是本博客所致力于做到的。

这所有都意味着什么？

首先，这意味这Python开发者们并不是不可能犯错的。没人会迫使开发者的生活更艰苦， 只是有些问题并不能及时发现而已。

其次，解决这个问题只会带来更多的危害，所有 PyCObject API还是没有重新启用。 尽管重新启用这个API可以帮助被这个改变所害的开发者，但总体而言，这样会使兼容性 问题更复杂。同时，我们不得不忍受这个问题，并且继续前进。我们学到了教训，下次我们再也 不犯相同的错误了。

这件事还表明，Python开发团队希望听到用户的意见。兼容性是非常重要的，所有的努力都想 让大家能无缝得过渡到新版本。特别的，库开发者们在有限的努力下必须尽量支持多个Python版本。

Finally, the developers haven't abandoned 2.7. While it won't be getting new features and there will be no 2.8, the views of people using 2.7 are still important. Making sure users can move to 3.x when they are ready is vital for the whole Python community. 最后，开发者们并没有抛弃Python 2.7。尽管它不会有新功能了，并且进来也不会有Python 2.8 版本，用户使用Python2.7的反映还是很重要的。确保让用户准备好后能够顺利迁移到PYthon 3.x 对整个Python社区来说是至为重要的。