Karin Dewar, 缩进 和 冒号

Karin Dewar, 缩进 和 冒号

我在另一个博客近期一篇博文中说了一个轶闻，是关于Robert Dewar的妻子如何发明Python缩进的趣事。当时我就提到自己并不十分确认具体细节，现在看来此举颇为明智，因为真相与之颇有偏差。我收到了Lambert Meertens一封详述此事的长电子邮件。我准备在此复述此信，除了部分他要求不要直接引用的部分外基本是信的全部内容了。摘要：Karin Dewar提供了ABC(因为也是Python)中在缩进开始前使用冒号的灵感，而不是缩进本身。下面是Lambert的电子邮件：

    Dewar的贡献不在缩进本身，而是发明了缩进前冒号的使用。

    首先是B中的缩进。在B0(B0，B1，B2, ... 是创建ABC时的一系列设计，B0最早)中就采用了强制缩进来分组代码，并且把分组代码用BEGIN和ENG分隔符包含起来。关于这点可以参考[GM76]的4.1节(布局)。如同打印美观一样，缩进被提议由专门的B编辑器来负责，而用户无法对此修改：用户没有被赋予取消这一设置的选择，以免缩进的强制性被破坏。

    有了强制性缩进后，额外的BEGIN和END分隔符自然就显得多余了，B1时我们就取消了BEGIN，只保留了END IF、END FOR等结束分隔符，在B2时结束分隔符也被取消了，只利用缩进作为分组代码的唯一标识。这一点可参考[ME81]第四章(语句语法)

    ABC中缩进的本意仅是为了使源代码看起来整洁，易于表达语义逻辑，把尚未强制的习俗固化下来，取消额外的BEGIN ... END可能受[PL75]影响，后者提倡仅用缩进来分组代码。occam出现(1983)的要晚，因此缩进这一特性不可能源自occam，同一原因，也不会是借鉴自Miranda(1985)。据我所知，B语言是最早采用缩进作为分组语句特性的且正式发布(并且有实现)的语言

    现在到了 Dewar 的故事，也就是我得知采用冒号的由来，我在此将其记录下来，也算是ABC设计理念的回忆录：

依 Lambert 要求，下面的内容由我组织语句而不是直接引用。

1978年，一次在Jablonna(亚布翁纳)召开的设计会议上，Robert Dewar, Peter King, Jack Schwartz 和 Lambert比较各种为B提议的语法，通过比较采用各种语法实现同样的(代码质量一般的)冒泡排序。他们僵持不下时便去Robert Dewar妻子的房间将她喊来，想听听她的观点，像是现代版的让Paris来从Hera, Athena, 和 Aphrodite之间选美。但是刚刚向她解说了第一个语法形式后，她说道：“你的意思是说，这样一行'FOR i ...'，必然会影响接下来的一组语句，而不会仅是影响当前行本身?!”于是，这些科学家们意识到在这样的行结束后附加一个冒号，就能避免误解。

Lambert 还提到如下相关文献：

    [PL75] P. J. Plauger. Signal and noise in programming language. In J. D. White, editor, Proc. ACM Annual Conference 1975, page 216. ACM, 1975.

    [GM76] Leo Geurts and Lambert Meertens. Designing a beginners' programming language. In S.A. Schuman, editor, New Directions in Algorithmic Languages 1975, pages 1–18. IRIA, Rocquencourt, 1976.

    [ME81] Lambert Meertens. Issues in the design of a beginners' programming language. In J.W. de Bakker and J.C. van Vliet, editors, Algorithmic Languages, pages 167–184. North-Holland Publishing Company, Amsterdam, 1981.

############################################################################
小广告：以前留言的朋友，由于博客的缺省设置，可能将部分留言作为广告信息自动屏蔽了，所以我当时没有看到留言，十分抱歉。现在修改了设置，应当能看到了。

2011 Language Summit Report

http://blog.python.org/2011/03/2011-language-summit-report.html


2011年语言峰会报告

今年语言峰会于3月10日星期四在亚特兰大召开，在 PyCon 会议前一天。出席人员包括来自 CPython、 PyPy 、 Jython 、 IronPython 和 Parrot  等 VM 代表，以及来自 Fedora 、 Ubuntu 和 Debian 的系统包维护人员；还有 Twisted 项目开发人员和若干其他人士。

开发 Blog

首先讨论的事项之一正是这个 Blog 本身，由 PSF 通信员 Doug Hellmann 发起。由于 python-dev 邮件列表日常讨论过多，希望借由这个 Blog 来方便用户获取开发资讯。我们计划包含 PEP 、重要决策、新特性与关键 bug 修复，将来还会包括下一步开发计划的非正式通报。

Blog 发文对所有 Python 实现开放。例如，即便 PyPy 当前已有自己的 Blog 且相当活跃，也欢迎他们在这儿发布信息。还有一个相关讨论就是在 python.org 的 download 页面提供对其它 Python 实现的介绍。这些实现的新版本发布时也将会在 python.org 主页作为新闻项目列出。

Compatibility Warnings

在 Python 3.2中我们引入了 ResourceWarning ，用于方便用户定位依赖 CPython reference counting 的代码。 ResourceWarning 不仅有利于用户书写高质量代码，也对书写跨 VM 代码有帮助。为进一步提高跨 VM 兼容性，提出了一个新的警告类型：CompatibilityWarning。

之所以这么做，是源于最近由 PyPy 开发人员提交的一个 CPython bug 。 Issue #11455指出 CPython 允许用户创建一个新类型时，其 __dict__ 可以有“非字符串” key ，而目前至少 PyPy 和 Jython 不支持这样做。现在，用户就可以类似 ResourceWarning 那样抛出 CompatibilityWarning 警告，以便于定位此类问题。

独立的标准库

现在 CPython 源代码已完成从 Subversion 到 Mercurial 的转换过程，再次兴起了将标准库放在单独 repo 的提议。其它实现的开发人员对此十分关注，因为这样将很大程度的简化其开发过程。其它实现现有方法比较繁琐，先对 CPython 的源代码做个快照，然后应用自身实现相关补丁，转换部分 C 扩展为纯 Python 实现，等等。

讨论结果的实施会由接下来的一个相应 PEP 来体现，其中之一是版本号规划问题。既然库不再依附任一具体实现而是独立存在，则应有自己的版本号，以后的测试也应有版本相关考虑。

标准库相关的讨论还涉及纯 Python 代码和对应 C 扩展的问题。PyPy 项目的 Maciej Fijalkowski 指出随着时间的推移，某些模块的 C 与 Python 版本出现细微差异，并建议修订这些模块时采取严谨审慎的策略，以便两种用户(纯 Python 实现的和 C 扩展的)都能平滑升级，这一点也达成了共识。另外，还决定，以纯 Python 实现优先，C 实现只用在能明显增加性能的场合。

测试性能网站

PyPy 的 Speed 中心十分成功的展示了 PyPy 的性能，由此讨论了在 python.org 设立类似网站的想法，初步打算命名为 performance.python.org ，各种 VM 实现均包含进来。不仅进行性能测评，还可包含内存占用、测试通过程度以及语言兼容性等指标。由于当前只包含 PyPy 和 CPython ，为了支持其它 Python 实现还需要进行系统安装设置方面的工作。

Allison Randal 在会上提议了在 Oregon State University 的开源实验室托管若干高性能电脑，恰好可用来作为新的 Speed 中心。Jesse Noller 谈了购置硬件事项--欢迎捐助！

如果您或者您的机构愿意资助 Speed 中心或其它方面的 Python 开发，请联系 Python 软件基金会，这儿是捐赠页面。


暂停解除

随着 CPython 3.3 开发的起步，暂停语言变化的限制已经失效。虽然闸门已经打开，语言变化仍然会采取保守态度，我们希望减慢进化的速度，这也有利于其它实现赶上 CPython 。虽然在暂停语言变化期间没有其它实现升级到3.x版本， PyPy 和 IronPython 最近已经实现了兼容2.7版本， IronPython 也开始3.x的规划。

至于 Python 3.3会有哪些变化，首先 PEP 380已被接受，该 PEP 引入了 "yield from " 语法，允许在一个 generator 中 yield 另一个 generator 。除此之外，近期内尚无其它语言变化。

异常属性

接下来简略讨论了异常提供属性以增加易用性的问题，而不局限现在这样迫使用户依赖字符串信息。例如在 ImportError 时，不应通过 parsing 手工分析何处 import 失败，而是提供相应属性。

实现很可能在初始化异常对象时依赖显式关键词( keyword-only )参数，当前已有针对 ImportError 情况的补丁。

贡献者协议

与会者还讨论了贡献者协议，并准备若干形式的电子协议。 Google 个人贡献者协议是设计新协议时的参考之一。这个话题的讨论已有很长时间，许多人希望能有电子版本的解决方案。由此，需要调研以保证将来使用电子版本的协议时在美国之外也有效。

Google Summer of Code


Martin von Lowis 简短介绍了今年在 PSF 名下的 Google Summer of Code 。我们鼓励开发者不仅作为导师，还鼓励他们提议项目，便于学生参与--而且提出项目并不意味着一定要作为导师。如果您有兴趣帮助我们，请参阅 PSF 的项目与导师征集通知。

Distutils

Tarek Ziade 带来了 Distutils2 ，指出他们正进行的 sprint ，目标在于完成到 Python 3 的移植并为最终合并回 Python 标准库做准备。另外，到时将会采用一个新的名称： packaging 。 packaging 项目组计划还提供单独的 Distutils2 库，以支持 Python 2.4到 Python 3.2。

packaging sprint 是 PyCon sprints 中规模最大的 sprint 之一，结果十分理想。当前代码在 Bitbucket ，只待合并回标准库。

其它VM展望

IronPython提到下一步计划，已包含 3.x 发布。他们在 PyCon 宣布了 2.7.0 ，这也是项目由微软转交为开源社区驱动后第一次新版本发布，然后准备接下来几个月向3.x进发

最近发布了2.5.2，而且计划实现2.6。有些人建议直接跳级到2.7，因为2.6和2.7之间的区别并不大，但是如果跳级，可能接下来新版本的发布会耽搁一段时间。“早发布，多发布”是会上一句格言，他们也有考虑2.6之后直接升级到3.x，然后再考虑2.6到2.7的问题。

开发资助

3.x计划还谈论了如何资助开发，以及资助对加速其它实现赶上3.x版本的重要性。目前有相应资金，需要向 PSF 提交申请后才会进行可行性论证。对此感兴趣，希望得到资金支持者请联系 PSF 。

Python 基准

Jim Fulton 谈到他称作“基准” Python 的概念。在部署 Python 应用时，他发现有的操作系统难以设置 Python 。恰好 Fedora 和 Ubuntu/Debian 的打包专家也在，我们得以进一步考察这个问题。

对 Fedora 而言，基准 Python 安装需要考虑操作系统是利用一张 Live CD 来完成的，因此只能是一个最小安装，和极少的依赖，这种最小化安装简化到仅能使系统运行起来。因此做了目录名称的变动，也没有包含 distutils 等标准库，而且有些库即使包含版本也较陈旧。

当前尚未有一个明晰的解决方案，但相关成员将会进一步研究以期解决该问题。

3.3 特性

会上还讨论了3.3可能引入的特性，包括两个 PEP 。PEP 382 讨论了 Namespace Packages ，会在将来合适时机实施，在合并 distutils 时也有提及。

PEP 393， 定义了一个灵活的字符串表示机制，也引起了讨论，而且有些同学希望将其作为 GSoC 项目。除了功能上的实现之外，还需要考虑性能与内存占用等方面以决定实现能否被接受。

Unladen Swallow

Unladen Swallow 目前处在 “休眠” 状态，当前并不适宜合并到 CPython 3.3。由于缺乏相关领域的专家参与，要取得进展需要数个方面的突破。在讨论时还提到是否资助有利于推动 Unladen Swallow 前进，若有兴趣，致函联系 PSF。

尽管 Unladen Swallow 处在休眠期，且前途未卜，它仍然对 Python 和开源社区很有积极意义。 例如 Unladen Swallow 的性能测评部分就对评测其它实现很有帮助。另外 Unladen Swallow 开发人员对 LLVM 和 Clang 的贡献也对这些项目有帮助。

还有两个性能相关的想法被简单提及，包括 Dave Malcolm 的函数内联提议。 Martin von Lowis 提及了他正在着手的 JIT 扩展模块，虽然 PyPy 开发人员对这种 JIT 的有效性持怀疑态度。

通往异步框架之路

临近结束时讨论了在某种程度上将 Twisted 集成到标准库中来的问题。基本想法是这样一个异步实现有助于把程序迁移到 Twisted 或者其它异步编程框架。

接下来就会有一个 PEP ，和 WSGI 参考类似，但是是针对异步事件循环( asynchronous event loops )的。除PEP 作者外还需要 Twisted 项目和其它相关项目人士须致力于达成共识。

更多信息

更多信息请参考 CPython 开发人员 Nick Coghlan 的笔记和要点。