原文链接： 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 。
No comments:
Post a Comment