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社区来说是至为重要的。

关于轮询，未来执行和并行执行

原文链接: Of polling, futures and parallel execution

现代计算的一个重要考虑因素是降低功耗。它对于移动设备（笔记本，平板，掌上电脑） 来说意义重大。你的新式CPU在空闲时会进入很多种低功耗状态。它空闲的时间越长， 低功耗状态越低，消耗的电能也越少，因此，你一次充电的电池使用时间就更长。

低功耗状态有一个死敌：轮询。可能只是为了读取内存地址来检测可能的改变，一个任务 会每隔一段时间唤醒CPU，CPU离开低功耗状态，唤醒他的所有内部结构，当你的间歇唤醒 进程完成它的任务很久之后CPU才能再次进入低功耗状态。这大大的削减了电池的寿命。 Intel公司自己 对此很焦虑 。

Python3.2带来了一个新的标准库模块来启动并行任务，并等待他们结束： concurrent.futures 模块 。 当我细读它的代码时，我发现它在一部分的worker线程和进程中使用了轮询。 我说“一些”是因为 ThreadPoolExecutor 和 ProcessPoolExecutor 的实现方式不同。 前者在它所有的worker线程中使用了轮询，而后者只在用来与worker进程通信的 队列管理线程中使用了轮询。

在这里使用轮询只是为了完成一个任务：检测是否应该启动关闭步骤。类似于queueing callables或者从以前的queued callable中获取结果等任务会通过同步队列对象来完成。 这些队列对象从threading或者multiprocessing模块中而来，具体是哪个取决于你所使用 的executor的实现方式。

因此，我想出了一个简单的 解决方法: 我用了一个sentinel来替换轮询，内置的sentinel是None。当一个队列接受到None时， 一个等待中的worker自然的被唤醒，并检查它是否应该关闭。对于ProcessPoolExecutor来说， 要多处理一个稍复杂的问题，因为我们需要唤醒除了那1个队列管理线程之外的N个worker进程。

在我最开始的补丁中，我还是会发生轮询超时；一个非常大的超时（10分钟），worker会在 那时被唤醒。这个大超时会存在是因为写的代码是有问题的，并且worker在接收到刚才提到 的sentinel时并不关闭。处于好奇，我深入到multiprocessing的源代码中，又发现了一个 很有趣的东西：在Windows平台， 使用非零非无穷超时的 multiprocessing.Queue.get() 使用了...轮询（为此，我提出了 issue 11668)。 它使用了很有趣的高频率轮询，因为它在开始的时候使用了1毫秒超时，并在每次循环中递增。

不用说它仍然使用了超时，而且是非常大的超时,这都会是我的补丁在Windows平台毫无作用， 因为超时的实现方式决定了每毫秒都可能被唤醒。因此，我硬着头皮移除了移除超时。我最新 的补丁完全没使用超时，因此在所有平台都不会引起间歇性唤醒。

Historically speaking, before Python 3.2, every timeout facility in the threading module, and therefore in much of multiprocessing since multiprocessing itself uses worker threads for various tasks, used polling. This was fixed in issue 7316. 从历史上来说，在Python3.2之前，threading模块中的所有超时工具，都使用了轮询。 因为multiprocessing模块使用了worker线程来完成各种任务，所以multiprocessing模块 中也存在同样的问题。这个问题在 issue 7316 解决。

ctypes维护者Thomas Heller退休

原文链接： Thomas Heller Steps Down as ctypes Maintainer

Python开发社区欠长期的 ctypes 维护者Thomas Heller一个大大的人情。这个月 初, Thomas 宣布退出 CPython项目。从Python2.5开始，他的 cytpes 库是CPython 项目的一个重要部分。

我有幸能够和Thomas交谈，他告诉了我他参与Python项目以及开始他自己的 ctypes 和 py2exe 项目的过程。

Python

回到1999年，寻找Python学习资料的期间，Thomas读了Mark Lutz的书 Programming Python ，马上Thomas就对这门语言非常执迷。那时他正在把 Scheme 替换为自己在Windows平台 上用C语言写的一个大程序的扩展语言。

当问及他是如何加入到开发组中的问题时，他表明他对CPython（以及开源项目）的第一次 贡献是提交了一个与Windows相关的 distutils 的小补丁。他对 distutils 的兴趣 最终引导他开发了能够创建Windows点击安装器的 bdist_wininst 命令。从那以后， Greg Ward邀请他加入python-dev群组，在那时他才最终获得了提交权限。

py2exe

跟很多Windows用户一样，他需要把封装得很好的Python程序部署成一个可执行文件。 在这之前的解决方案有：Fredrik Lundh的 squeeze 和 Christian Tismer的 sqfreeze 。 Thomas还为Gordon McMillan的 Installer 项目贡献了很多补丁。

His interest in distutils led Thomas to consider porting Installer to an extension to the packaging library. However, he ended up rewriting the source in order to make use of the existing distutils framework. In the end, he chose the simple yet descriptive name py2exe for the project. Thomas对 distutils 的兴趣让他考虑把 Installer 移植成库的扩展。然而，为了 使用当时已存在的 distutils 框架，他最后完全重写了源代码。最终，他给项目取了 一个简单但很能解释项目目的的名字 py2exe 。

ctypes

ctypes 项目的初衷是需要超越当时 pywin32 提供的功能。此外，他Scheme的任务 需要的Windows API接口正好和他的Python工作很像，因此他想要保持他的项目继续进行。

当Python2.3在2003年发布时， ctypes 也第一次对公众亮相。在那之前，Thomas收到了 很多让他发布项目的请求。他在他的 Starship page 提到了他的这个个人小项目，但不久 这个项目成为了一个广泛使用的库。

他的原始项目是在Windows平台上开始的，但不久很多人把它提出移植到Linux的需求，在 社区的帮助下，Linux移植版顺利完成。在移植到Linux的过程中 libffi 加入到了项目， Thomas马上在Windows项目上用 libffi 替换了底层实现。

2006年 ctypes 迎来了1.0版本发布，同时受到肯定加入到了Python2.5的标准库之中。 经历了多年的辛苦工作以及每年无数次的新版本发布， ctypes 现在已经跟标准Python绑定， 更多的用户可以直接使用它了。

ctypes 能有今天多亏了很多人的辛苦工作，Thomas想要感谢每一位参与其中的，尤其是 Robin Becker。早在项目的开始阶段Robin就开始提供指导，贡献他的知识以及鼓励。

新任ctypes维护者

见证了Thomas这些年来的所有辛苦工作，我们很不忍心看到ctypes项目搁置起来。如果你 有C语言的编程经验以及足够的空余时间来帮助Pyhton项目，社区会很感谢你的努力。 请查看下新的 开发者向导 并搜索下 the bug tracker 来获取更多信息。