2011 Python 语言峰会报告

浏览数：29 / 时间：2015年06月08日

原文链接： 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的开发者对这种做法的效率持怀疑态度。