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