Wednesday, September 7, 2011

成员面对面: Michael Foord

原文链接: placeholder

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

姓名:Michael Foord
地址:英国, 北安普敦
主页:http://www.voidspace.org.uk/

你使用Python多久了?

我一开始使用Python是2002年, 那时只是把它当做业余爱好. 从2006年开始我 开始全职使用Python. 第一次接触的Python缘由是我们几个人想要写一个通过email 玩的游戏. 当时我们几个人都有一段时间没写过程序了, 本来我们打算使用smalltalk, 后来有人建议我们试试Python. 然后我就飞快地和Python陷入爱河了.

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

是从2009年的PyCon开始的. 最初是因为我在IronPython项目上做的一些事情.

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

在PyCon 2009冲刺阶段我和另一名核心开发人员Gregory Smith一起, 当时是要把 google贡献的一些unittest改进合并进来.

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

在刚开始PyCon冲刺中unittest的那段工作以后, 我接着修正了unittest的一些其他 问题, 而且对unittest做了一些改进. 当时unittest还没有维护者, 于是我就成了 unittest的维护者, 不过我也在其他的标准库上面做过一些贡献.

我还在一些其他的次要方面做一些支持Python的工作, 例如维护Planet Python, 作为一名PSF成员, 帮助管理一下python.org等等.

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

我的全职工作是为Canonical做web开发. 我负责的是围绕Canonical网站的一些 web服务内部架构, 还有一些集成到Ubuntu中的服务. 工作本身很有趣, 我们的团队 也很给力.

闲暇时间我的工作主要放在unittest2 (改进版unittest模组在其他平台上的backport), mock (一个代码测试工具库, 为测试提供模拟物件和monkey patch支持), 还有其他 一些小项目上面.

我也想多写一些东西, 不过我已经花了两年的好时光写了IronPython in Action这本 书, 所以近期怕是不会开始大的写作项目了.

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

嗯, 在过大约四周我的第一个小孩就要出生了 -- 所以我现在的回答可能很快就不 适用了.

我是北安普敦(英国)一所教堂的积极参与者, 我花了不少时间在上面, 而且是我们 一个慈善项目的管理者. 在Canonical这家公司工作的好处之一是我可以在家办公. 这样我就可以扎根在这里, 不用到处搬家了 (我当然不是因为天气好才呆这里的, 而且想必大家都知道, 北安普敦这地方不是Python编程的活跃地区). 我的第一次 全职编程高峰期是在伦敦的一个超赞的团队里面, 然而每天上下班单程要两个小时. 我就这样坚持了4年, 而且非常享受这份工作. 不过现在我总算是逃脱了上下班路程 的苦恼, 我觉得我不会再回到老路上去了.

我还喜欢玩XBox游戏. 不幸的是, 如果我碰到喜欢的游戏, 就会陷入里边几个星期 无法自拔, 所以我得非常小心, 为此我已经避开了魔兽世界(World of Warcraft)和 星战前夜(EVE Online)... 我还组织了一个北安普顿的每月geek聚会. 虽然这里的 Python程序员的数量不够组织一个Python用户组, 不过这里格式各样的geek还是挺多 的. 我们一般都在酒吧里聚会, 一起侃侃大山, 或者展示一下自己最近做的一些小 玩意.

Thursday, August 25, 2011

成员面对面: 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年夏季的高温中失去了 我的电视对我来说是一件意外的好事;而和我的妻子结婚是我有意为之所做的最好 的事情 =). 在其他时间,我经常做做阅读,主要是看看杂志和一些网站,还有好些 一直在看而没看完的书.

Tuesday, July 12, 2011

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 邮件组的讨论内容包含了一些关键的内容:

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/。

Wednesday, July 6, 2011

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() 的问题。另外我们针对问题 #12175readall 方法做了清理,让它在 read() 返回 None 的时候也返回 None,而在无法打开文件时抛出 ValueError

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

Windows

3.2.0 为 Windows 带来一个新功能,也就是 os.symlink 的支持。随之而来的就是 #12084os.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 。有了大家的帮助,我们就可以保证新版的质量,谢谢大家。

Wednesday, June 15, 2011

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.statos.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 提交给我们。

Saturday, June 4, 2011

2011Python语言峰会报告

原文链接: 2011 Language Summit Report

今年的语言峰会于c3月10号星期四在亚特兰大举行,正好是PyCon会议部分开始的前一天。 到场的有 CPython, PyPy, Jython, IronPythonParrot 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 noteshighlights

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线程和进程中使用了轮询。 我说“一些”是因为 ThreadPoolExecutorProcessPoolExecutor 的实现方式不同。 前者在它所有的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项目以及开始他自己的 ctypespy2exe 项目的过程。

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 来获取更多信息。

Saturday, May 21, 2011

葡萄牙语、德语、韩语、以及繁体中文翻译分站上线

原文链接: Portuguese, German, Korean, and Traditional Chinese Translations

Python Insider 翻译项目 的翻译团队还在不断扩大中。今天 Python Insider 的 葡萄牙语德语韩语 、以及 繁体中文 版的翻译已经正式上线。旧文章的 翻译也都在进行中。和其他的翻译分站一样,相比主站 Python Insider 来说。这些 并行版本的文章发布可能会有一些延时。

Saturday, May 14, 2011

正式确定改变AST的控制原则

原文链接: Formalizing the AST Change Control Policy

Python 在 AST 模块 中提供给 大家能够表示Python 源代码编译后形式的抽象语法树(AST)。用户可以通过AST模块在解析 和编译字节码之间审察和控制AST的表示形式。

尽管在 language reference 中 定义了Python 代码, AST 模块只是CPython 实现的细节,而不是其他Python实现必须的。

AST 的兼容性

work 中一部分指明要重写CPython的peephole 优化器,使它能工作在AST上(而不是像当前这样工作在原始的字节码上),因此Eugene Toder 觉得需要对AST的结构做一下调整。 作为一个CPython 实现细节, AST的向后兼容 原则并不是非常的明确。因此, Eugene在 python-dev 中 提出了这个问题. 当改变AST时,是否需要确保向后兼容性?

大家的一直意见是兼容性是 必要的。AST模块中有一个常量, ast.__version__, 能够让用户代码根据AST的版本来改变行为。这对那些针对特定Python实现的模块能够提供 足够的兼容性。

其他的Python实现

实际上,Jython 和 IronPython 维护者都指出他们相应的实现中要么会有一个兼容版本 的AST模块,要么会自己打算提供一个。即使这样,他们也觉得不应该冻结AST,而且很支持 AST模块根据 ant.__version__ 常量的改变以不兼容的方式进行修改。

还有一点需要指出的是: test_ast.py 中的全套测试很够帮助其他Python实现 确保他们的AST 表示形式是和CPython相兼容的。对于那些想参与到Python内部实现的人来说, 提升 test_ast.py 的覆盖范围是个很好的项目。

接下来会发生什么?

那个引发讨论的 补丁 还没放入CPython。 因此,有可能,什么都不会发生。然而,如果这个补丁通过了,那么 AST 将会 以不兼容 的方式改变。 ast.__version__ 常量会相应的进行改变,因此用户的代码会知道 这个变化,而且改变确实是需要的。更一般的说法是,将来AST也会按照这种方式改变。

Python开发者们很想知道AST模块使用程度到底有多广,以及这个原则到底影响会有多大。 如果有读者朋友的代码会收到影响,欢迎参加 python-dev上的讨论.

urllib/urllib2 修复一个安全漏洞

原文链接: urllib Security Vulnerability Fixed

Guido van Rossum 针对 CVE-2011-1521 提到的Python URL库中的安全问题 最近提交了一个补丁. 尽管安全问题很少,但这提供了机会让社区了解当问题产生时如何报告,处理以及解决的步骤。

报告问题

当你发现了CPython的安全问题时,首先要做的事情是把问题细节保持隐蔽。当你确定 发现的是真正意义上的安全漏洞的时候,请提供给核心开发人员一份语义明朗,内容详细 的报告。

一份好的报告需要清晰的解释这个安全漏洞影响了系统的哪些相关部分。如果能提供安全 漏洞发生的特定平台和相应的依赖关系,就更好了。能知道受影响的版本是很有帮助的, 尽管这个安全漏洞一般会针对当前所有的有效版本进行测试。最后,如果你有相关的测试 用例,也请附带提供。报告的接受地址是: security@python.org.

来自Google 安全组的Niels Heinen 最近 提交了一份很好的报告. 他发现了标准库 urlliburllib2 模块中存在的处理HTTP 302 重定向的一个问题。他发现 服务器会把请求转发到不合理的scheme,这样会危及数据甚至是整个系统。在他最初的报告 中,他解释了这种重定向会导致问题的2种情形。

第一:因为 urllib/urllib2 会处理 file:// URL scheme, 如果重定向 到 file:///etc/passwd 就可能暴露所有的密码信息。 第二,Neils还指明,当 重定向指向一个类似于 file://dev/zero 的系统设备时,就能引起系统资源的损耗, 造成拒绝服务攻击。

处理报告

处于安全报告的敏感性, 只有很少数受信任的开发者维护着 security@python.org 列表,他们会尽快分析问题并采取相应的对策。如果你想提交加密报告,请查看在 security news 页上关于 OpenPGP 的详细信息。

如果安全组确认确实存在这样的安全漏洞,他们会公开发表这个bug报告,并提供相应 的补丁。在我们现在这个例子中,Guido van Rossum 完整公开了 issue #11662,以及 相应的补丁。

解决问题

Guido的补丁主要是限制了重定向只能到 http://, https://ftp:// URL scheme。 FTP重定向是可以接受的,因为这在FTP 中是经常发生的: 下载镜像时,系统 经常会把请求转发给地理位置更近也更方便的FTP 服务器。

在 Python 2.x版本中, 当重定向到一个不合理的URL scheme时, FancyURLopenerredirect_internal 方法会抛出一个 IOError 异常。 HTTPRedirectHandlerhttp_error_302 方法也这样处理,它会抛出 HTTPError 异常。 在Python 3 版本中, urllib.request 也用同样的方式解决了问题。在提交的补丁中 还包括了2组 针对有效和无效重定向的测试。

对于正接收补丁的用户,还要提及几点,Python 2.5 最后的安全发行版本马上会发布。 尽管对于其他的维护分支- 2.6, 2.7, 3.1 和 3.2 还没有明确的日程发布相应的漏洞 修复版本,但这些分支都已经修改相应的代码解决了漏洞。

Friday, May 13, 2011

Python 3.3 新增了 faulthandler 模块,用来帮助调试

原文链接: New faulthandler module in Python 3.3 helps debugging

当用户报告你的程序崩溃了或者僵死了,有时你只能试着搜集有用信息,概括当时 的场景,以便能够重现错误。即使有了一个可靠的用户场景,作为开发者的你经常会 无法重现错误,因为你们的环境相差很大,比如操作系统和编译器。当用户安装了调试 工具时你会幸运一点,但大部分情况下你只能等待其他人能够从这相同的情形下获得 更多的有用信息。

致命错误

Python 3.3 中新引入的模块可以帮助处理这个问题: faulthandler. faulthandler 在Python碰到类似于段错误,除0, 中止程序和总线故障等的致命错误(fatal error) 时 能dump 出 trackback。 你可以通过在你的应用程序中加入 faulthandler.enable(), 或者调用Python 可执行程序时提供 -X faulthandler 参数,或者设置 PYTHONFAULTHANDLER=1 环境变量来启用该功能。 输出类似如下

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

超时

通过调用 faulthandler.dump_tracebacks_later(timeout), faulthandler 能 在超时时dump出traceback。再次调用该函数可以重启计时器,或者调用 faulthandler.cancel_dump_tracebacks_later() 来关闭计时器。 输出类似如下:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

使用 repeat=True 选项可以在每 timeout 秒后dump一次traceback, 或者用 exit=True 选项使程序立即不安全(不会把文件全部写入磁盘)退出。

用户信号

如果你有程序运行所在的主机的访问权限,你可以使用 faulthandler.register(signal) 来注册一个处理信号句柄, 当 single 信号收到时,可以dump 出 traceback。 在Unix系统上,你可以使用 SIGUSER1 信号: kill -USER1 <pid> 将把当前的 traceback 给dump 出来。这个特性在Windows系统上时没有的。 输出类似如下:

Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

另外一种方式是在你的程序中显式调用 faulthandler.dump_traceback() .

安全问题 以及 输出文件

由于安全因素 faulthandler 默认时关闭的, 主要是因为它保存了 sys.stderr 的文件描述符, 并把trackback写入那个文件描述符。如果 sys.stderr 被关闭了, 但这个文件描述符被重用了,那这个文件描述符可能是个socket,管道,一个关键文件或者 其他什么。默认情况下, faulthandler 把traceback 写到 sys.stderr 中, 但你可以指定其他文件。 更多相关的信息可以查阅 faulthandler 文档.

旧版Python的第三方模块

PyPI 上``faulthandler`` 作为Python 2.5版本到 3.2版本的第三方模块维护。 Python 3.3 标准模块和第三方模块的主要区别时 dump_tracebacks_later 的实现方式: Python 3.3 使用线程的锁超时,而第三方库使用了 SIGALRMalarm()

作为Python 3.3的新特性, 锁超时的精度是1微妙。旧版Python上的 alarm() 的精度时1秒, SIGALRM 信号可能会中断当前的系统调用, 使系统以 EINTR 错误 失败。

早已取得成功

faulthandler 新模块已经在我们的buildbot项目中帮助我们跟踪竞争状态。我们希望 它也能在你的程序中帮助你。

Wednesday, May 11, 2011

成员面对面: Benjamin Peterson

原文链接: Meet the Team: Benjamin Peterson

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

姓名:Benjamin Peterson
地址:美国,明尼苏打
主页:http://benjamin-peterson.org
博客:http://pybites.blogspot.com

你使用Python多久了?

3年半。

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

到今年三月25日恰好是整3年。

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

我的第一个提议被 被Guido本人否决了. 幸运的是,我还是坚持了下来,我的一些补丁也被接受了。我认为我的第一次提交是 调整Misc/ACKS文件的内容顺序。

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

我喜欢解析器,编译器以及解释器核心,但很多人都了解我涉足过除了Windows以外的 几乎Python 核心开发的每个部分。

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

我用python来实现一个Python 解释器! 说真心话,我内心认为我自己是一个Python实现 者。:) 我是six(http://pypi.python.org/pypi/six)的创始人, 这是一个Python 2 和 3 都兼容的库。

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

创造音乐,玩玩单簧管, 还看看数学书籍。有时也会去玩玩登山。

欢迎访问 Python Insider!

原文链接: Welcome to Python Insider!

Python Insider 是 Python 核心开发组的官方博客。如果你不是邮件组的 成员,你可以从这里大致了解到邮件组中讨论的内容,尤其可以了解到 Python 可能发生的变更。我们将在这里写下核心开发组最近发生的主要事项, 例如向 Mercurial 的迁移、新核准的 PEP (Python Enhancement Proposal)、 以及 API 的变更等。

我们并不打算用这个博客代替 python-dev 邮件组 以及开发人员的个人博客 (见边栏的链接),这个博客的目的是在项目完成时发一个消息出来供大家讨论, 或者是某个项目需要帮助时向大家求援。我们欢迎跟帖讨论,不过我们更期望 你能加入 python-dev 邮件组直接参与讨论以及跟踪整个开发过程。

你可以把这个博客当做了解 Python 语言演化的一个窗口。

订阅

你可以通过下面的方式跟踪和阅读 Python Insider:

寻求帮助

我们已经有了一个专门的作者团队。目前我们需要会网站设计的人帮忙 设计一下网站模板。如果你可以帮我们为博客整整容的话,请联系 Doug Hellmann (doug dot hellmann at gmail)

成员面对面: Tarek Ziadé

原文链接: Meet the Team: Tarek Ziadé

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

姓名:Tarek Ziadé
地址:法国, 布根地,第茂附近的Turcey
主页:http://ziade.org

你使用Python多久了?

差不多有10年了。

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

自从2008年12月21日到现在。

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

我开始成为核心开发人员主要是为了维护Distutils模块,并让他有更多的功能。

我作为核心开发人员的第一次代码提交是为了修复distutils新特性中的一个小bug。 那个特性是我成为代码提交者之前提出的,也刚好在当时的前一周加入Python中。 这个特性能使我们配置Distutils的register, 上传命令以和类似pypi的服务器更好的交互。

我使用全新的权限提交了代码,当时是2008年12月24日星期三,正好是我的生日,也恰恰是 Python 0.9.4版本release的17周年纪念日。

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

我主要负责标准库中的sysconfig, distuils, packaging(会在3.3版本加入), shutil, pkgutil模块, 偶尔也负责下其他的模块。

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

我在Mozilla的Service组中工作,我在那用python构建web service。

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

我会看看漫画,写写书,和我孩子们玩耍,与我的妻子品酒,并试着翻新我那始于1848年 的旧房子。

Tuesday, May 10, 2011

新版博客版面设计

原文链接: New Blog Design

如果你通过RSS阅读器来阅读 Python Insider 的内容,你可能看不到 Marcin Wojtczuk 为我们设计的新的页面样式。它看上去非常不错,并且给人 以简单清爽的感觉, 我们对这个效果非常满意。

Marcin, 感谢你付出的时间和努力。

罗马尼亚语 和 简体中文 翻译工作

原文链接: Romanian and Simplified Chinese Translations

今天Python Insider团队很高兴公布2个新博客。 罗马尼亚语简体中文 的翻译人员 加入了 翻译项目,并已经开始发布旧博文的翻译版。和几天翻译版一样,这些并行 的版本会稍微滞后于 Python Insider 原来的文章。

Monday, May 9, 2011

成员面对面: Brian Curtin

原文链接: Meet the Team: Brain Curtin

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

姓名:Brian Curtin
地址:芝加哥, 伊利诺伊州
主页:http://blog.briancurtin.com/

你使用Python多久了?

在持续6年的时间里每天都用。在那之前我偶尔会在大学的课程上和夏季实习期 间使用python。

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

才刚刚超过一年。3月24日是我加入开发组一周年的日子。

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

我开始起步是在工作中写扩展模块时注意到了一个文档bug,然后我提交了一个 简单的补丁,Georg Brandl立刻就确认通过了它。有了那次快速的成功经历,和 一次全新的源代码检出,我就很想深入项目并学习更多关于我当时正在使用的 模块,最后我写了一个能让zipfile支持上下文管理器的补丁。

为了便于起步,我最初的几次提交都是文档内容的修复。我最早提交的代码是给 winreg模块增加一下新的特性并扩展的它的测试涵盖范围。

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

作为参与CPython开发项目中的少数的Windows用户中的一员,我设法关注Windows 用户碰到的所有问题。因此,我有机会致力于维护很多标准库,包括很多我从来 没有使用过的。我还没有做过任何更解释器相关的任何工作,但我正在找机会做出 改变。

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

我为一个用C++写的商业数据库建立了很多测试工具。那儿提供了一个数据API的 扩展模块,这样我们可以很方便的编写回归测试,性能测试。并且我们总是想建 立更多的测试。

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

我是一个狂热的棒球迷。春季我当一个大学棒球的裁判员,在夏季则是很多社团的 裁判,同时我还经常去看芝加哥小熊队的比赛。

成员面对面: Nick Coghlan

原文链接: Meet the Team: Nick Coghlan

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

姓名:Nick Coghlan
地址:布里斯班, 澳大利亚
主页:http://www.boredomandlaziness.org

你使用Python多久了?

在1999年我第一次接触python的1.5.2版本,当时我的讲师在一门网络课程中使用它。 从2002年的2.2版本开始我业务上主要使用python来做自动化测试,从此一发不可收拾。

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

2005年Guido给我了权限来更新PEP343(主要围绕上下文方法)

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

随着我开始贡献补丁,我在2004年有了3个月的空余时间,于是和Raymond跟Facundo 一起修改decimal模块,主要是跑telco基准测试并找方法来提升代码的速度。 decimal模块中很多奇怪的hack(比如检测特殊情况的快速路径,以及在转化由数字 构成的元组到整数类型时字符串的使用)都是源自于那段时间。

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

runpy,functools和contextlib是经常在我收件箱中出现的东西。我还留意着Brett和 Victor从事的import,Raymond处理的collections和itertools,以及其他跟编译器 有关的东西。我还执迷于跟文化有关的东西。

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

很少。工作中用python很快就完成了任务,当前根本就没有机会需要hack它。 我确实很想清理下我的数字音乐库,而现在要完成这个任务的工作所需要的脚本 只需要hack一把就行了。

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

跆拳道,电脑游戏,足球,阅读等等,等等。。。

Sunday, May 8, 2011

Jython 已迁移至 Mercurial

原文链接: Jython Migrates to Mercurial

Jython 终于从 Subversion 迁移至 Mercurual 了! 迁移的过程确实有些坎坷, 原因是我们 的 Subversion repo 不够平易近人, 要干净地转到另外一个版本控制系统还真要花不少 功夫.

新的 Jython 官方 repo 现托管于:

http://hg.python.org/jython

同时我们还设立了一处 BitBucket 镜像 以方便 forking.

另外还有一个更大的只读 repo, 其中包含持续开发的功能分支 (已转换为 Mercurial 书签). 该 repo 托管于 http://hg.python.org/jython-fullhistory

Mercurial 使得贡献 Jython 更为容易了, 欢迎你拉一支 fork 来帮助我们建造 Jython 2.6!

Thursday, May 5, 2011

Python 3.3 将放弃对 OS/2, Windows 2000 和 VMS 的支持

原文链接: Python 3.3 to Drop Support for OS/2, Windows 2000, and VMS

基本上每隔一段时间, 我们都会依据使用状况来对所支持的操作系统列表做一些增删.衡量增删的最重要的原因是各个平台开发人员的数量, 因为我们需要足够的开发人员以保证发行版的质量. 其他一些因素也在考量范围之内, 例如操作系统的年龄周期以及开发是否停滞等.

Victor Stinner 最近提议在CPython中 放弃支持 OS/2 和 VMS, 这已经是在他提出 最初问题 的一年以后了. Victor 最初提问时, 他正在竭力处理 Unicode相关的问题, 尤其是关于 os.execvpe() 通过 PEP 383 的 surrogateescape handler支持环境变量的一个问题. OS/2 和 VMS 目前在开发组中没有负责人, 而且在发布过程中并没有专门的测试.

写这篇帖子的过程 让我想到了 以前关于移除 Windows 2000 支持的 讨论 ,不过以前的讨论好像已经被闲置了. 当时的讨论还打算将 COMSPEC 设为 command.com的系统也一并取消支持. 从现在开始 , 这两者都已经加入了 OS/2 和 VMS 的行列.为了让开发工作更容易, Windows 2000 将被取消支持, 这样我们就不用考虑一款2010年已经生命结束的操作系统里的古老API了.

为了开始移除对于这些系统的支持, 我和 Victor 已经开始更新 PEP 11.

PEP 11

这篇 PEP 提供了不再支持的操作系统列表, 并且解释了将操作系统添加到这份列表中的流程.

一旦决定操作系统可以开始移除支持的流程, 该系统将被正式宣告为不支持的系统.该声明通常在开发中的版本生效, 所以取消 OS/2, Windows 2000 和 VMS 的支持将从 Python 3.3 开始.

第一阶段只是一个放手阶段, 可以说是举举白旗, 告诉大家已经没有人维护代码以保证发行版的质量了. 编译和安装的过程可能会做些改动, 用来提示这些平台的用户,告诉他们这些平台已经不支持了. 文档中的 "What's New" 部分也会列出新加的不支持的平台.

在一个"不支持"的发行周期之后, 下一个版本将会变成移除代码的公平游戏. 以这次的情况来看, 代码可以在 3.4 中移除. 也许不会把所有的代码全盘移除, 但开发者在正常工作中碰到相关的代码时可能会移掉里边的任何 #ifdef 片段, configure段落, 或者过时的代码.

你可以做什么?

如果你是 OS/2 或者 VMS 的用户, 你可以通过下面这些事情来拯救你的平台.

成为维护者

如果你能成为一名活跃的开发者, 那就是对 Python 最大的支持了. Andrew MacIntyre已经维护 OS/2 很长时间, 他在 Victor 一开始提问时就说过 Python 在 OS/2 平台的Unicode 支持已经落后, 所以这片领域确实需要集中精力搞搞. VMS 平台大致可以通过http://www.vmspython.org 得到一些外部支持, 不过正如 issue 11918 讨论过的,需要有人站出来才可以让 VMS 的上游支持继续下去.

如果你对上述任何平台的开发有兴趣, 请参见 developer's guide 以了解现行的开发流程.

贡献一台 build slave

有了一个活跃的开发者, 一个平台就有更好的机会生存下去. 有了一台 build slave, 一个平台的机会就更大了, 不仅是生存的机会, 而且质量也会得到保障.

Python 使用 Buildbot 来做持续集成, 至于build slave, 目前我们 提供 了对于 Linux, Mac, Windows, 以及 Open Indiana (Solaris) 各种版本, 各种架构, 以及各种配置的机器. 如果你能向 "build 舰队" 捐献一台 OS/2 或者 VMS 的机器的话,这些平台受到的关注将和其他更主流的平台一样多.

如果你可以通过捐献时间或者硬件让我们继续支持 OS/2 和 VMS 的话, 请联系 python-dev邮件组以协调你的努力.

Python Insider 翻译项目

原文链接: Python Insider Translation Project

我们认为这个博客的内容对于整个Python社群都是有用的, 所以我们优先要做的事情之一就是让尽可能多的人看到这个博客. 为了达到这个目的,我们组织了一个翻译群组来将这个博客的内容并行翻译成别的语言. 有两种翻译今天已经上线: 日语, 西班牙语.

Python Insider 的内容相比, 翻译的内容通常会较晚才发布出来,不过我们会尽量同步发布翻译内容.

寻求帮助

翻译团队目前还很小, 我们期待更多人加入. 我们需要有人加入已经发布的语言项目里面, 或者帮助我们扩展其他语言的翻译. 不管是两种方式的哪一种, 如果你能帮上忙的话, 请联系Doug Hellmann (doug dot hellmann at gmail).