摘要

大多数 CPython 跟踪器问题被分类为行为或增强。大多数行为补丁会被反向移植到现有版本的各个分支。增强补丁仅限于成为下一个 Python 版本的默认分支。

本 PEP 提出放宽对应用增强功能的限制，这些增强功能适用于位于 …/Lib/idlelib/ 中的 IDLE 代码。在实践中，这意味着 IDLE 开发人员无需对补丁进行分类或达成分类协议，而是可以专注于对 IDLE 用户和未来 IDLE 开发最有利的内容。这也意味着 IDLE 补丁不必一定拆分为“错误修复”更改和“增强”更改。

本 PEP 将适用于现有功能的更改和小功能的添加，例如需要新的菜单项，但不一定适用于可能的重大重写，例如切换到主题小部件或选项卡式窗口。

动机

本 PEP 由跟踪器和 pydev 列表上关于向右键上下文菜单添加剪切、复制和粘贴功能的争议引发（问题 1207589，于 2005 年打开 [1]；pydev 线程 [2]）。这些功能可以通过键盘快捷键使用，但不能在上下文菜单中使用。至少在 Windows 上，当适用时，它们是标准的（只读窗口仅具有复制），因此用户不必在选择要剪切或复制的文本或要粘贴的片段点后切换到键盘。上下文菜单直到添加新选项前 10 天才被记录（问题 10405 [5]）。

通常，如果行为与被认为正确的文档冲突，则称为错误。但是，如果没有文档，标准是什么？如果代码本身就是文档，那么跟踪器上的大多数 IDLE 问题都是增强问题。如果我们用合理的用户期望（当然，这本身可能存在争议）来替代，那么更多的问题都是行为问题。

对于上下文菜单，人们对添加内容的状态（错误修复或增强）存在分歧。即使是称其为增强功能的人，对于是否应该反向移植补丁也存在分歧。本 PEP 提出通过明确允许比其他标准库模块更宽松的反向移植来使状态分歧变得无关紧要。

Python 拥有许多高级功能，但 Python 因其作为初学者易于使用的计算机语言而闻名 [3]。Python 的主要理念是“自带电池”，这在 Python 的标准库中得到了最好的体现，其中包含许多其他编程语言通常不包含的模块 [4]。IDLE 是 Python 工具箱中一个重要的“电池”，因为它允许初学者快速上手，无需下载和配置第三方 IDE。IDLE 代表着 Python 社区对鼓励将 Python 作为教学语言（在正式教育环境内外）的承诺。建议的教学经验是让学习者从 IDLE 开始。本 PEP 及其将启用的工作将使 Python 社区能够通过使 IDLE 成为初学者开始使用 Python 的简单工具，从而使学习者在 IDLE 上的体验变得很棒。

基本原理

人们主要通过运行图形用户界面 (GUI) 应用程序来使用 IDLE，而不是通过直接导入 idlelib 中实际上是私有的（未记录的）实现模块。无论他们使用 Shell、编辑器还是两者兼而有之，我们相信他们从当前 Python 版本的最新版本之间的一致性中获得的好处，要大于从一个 Python 版本的错误修复版本内的一致性中获得的好处。当现有行为显然不令人满意时，这一点尤其正确。

当人们使用标准解释器时，操作系统提供的框架对于所有 Python 版本都是相同的。例如，如果 Microsoft 要升级命令提示符 GUI，则无论在其中运行哪个 Python，改进都会存在。类似地，如果使用编辑器 X 编辑 Python 代码，则右键上下文菜单和搜索替换框等行为不取决于正在编辑的 Python 版本，甚至不取决于正在编辑的语言。

IDLE 开发人员的好处是混合的。一方面，测试更多版本并可能不得不调整补丁（尤其是对于 2.7）需要更多工作。（当然，可以选择不反向移植所有内容。对于问题 12510，对类调用提示的一些更改未包含在 2.7 补丁中，因为存在与旧式类相关的问题 [6]。）另一方面，自行车棚可能耗费精力。如果错误的明显修复看起来像一个增强功能，那么编写单独的仅错误修复补丁需要更多工作。并且使代码在不同版本之间发生分歧会使未来的多版本补丁变得更加困难。

搜索和替换对话框说明了这些问题。它曾经对某些用户输入引发异常 [7]。未捕获的异常导致 IDLE 退出。至少在 Windows 上，退出是静默的（没有可见的回溯），如果 IDLE 是从图标正常启动的，则看起来像崩溃。

这是一个错误吗？IDLE 帮助（在当前的帮助子菜单上）只是说“替换…打开搜索和替换对话框”，并且确实打开了一个框。一般来说，库方法引发异常不是错误。而且，库方法忽略其调用的函数引发的异常通常也不是错误。因此，如果我们在没有详细文档的情况下采用“代码=文档”的理念，则可以说“否”。

但是，IDLE 在不需要时退出绝对令人讨厌。因此，我们中的四个人同意应该阻止这种情况。但是，仍然存在关于接下来该做什么的问题？捕获异常？不要引发异常？发出蜂鸣声？显示错误消息框？还是尝试对用户的输入做一些有用的事情？用有用的行为替换“崩溃”是否为增强功能，仅限于未来的 Python 版本？IDLE 开发人员是否需要询问这一点？

向后兼容性

对于 IDLE，可能有三种类型的用户可能关心向后兼容性。首先是将 IDLE 作为应用程序运行的用户。我们已经在上面讨论了他们。

其次是导入其中一个 idlelib 模块的用户。据我们所知，这仅用于启动 IDLE 应用程序，我们不建议破坏此类用法。否则，这些模块未记录且实际上是私有实现。如果将 IDLE 模块定义为公共的、有文档记录的，并且可能移动到 tkinter 包，则它将遵循正常规则。（为 IDLE 代码开发人员记录私有接口是一个单独的问题。）

第三是编写 IDLE 扩展的用户。保证的扩展接口在 idlelib/extension.txt 中给出。这至少应该在现有版本中得到尊重，并且不应在未来版本中随意更改。但有一个警告是“扩展不能对这个 [EditorWindow] 参数做太多假设”。此保证很少会成为补丁的问题，并且该问题并非特定于“增强”与“错误修复”补丁。

碰巧的是，在应用上下文菜单补丁后，发现添加了上下文菜单项（很少见）的扩展程序将被破坏，因为该补丁 a) 向标准 rmenu_specs 添加了一个新项，以及 b) 预期每个 rmenu_spec 都将被加长。目前尚不清楚这是否违反了保证，但有一个第二个补丁修复了假设 b)。当第一个补丁不必被恢复时，应该应用它。

参考文献

版权

本文档已进入公有领域。