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).