摘要

大多数 CPython 跟踪器问题被归类为行为或增强。大多数行为补丁会回溯到现有版本的分支。增强补丁仅限于默认分支，该分支将成为下一个 Python 版本。

本 PEP 提议放宽对 IDLE 代码（位于 …/Lib/idlelib/）应用增强的限制。实际上，这将意味着 IDLE 开发者不必对补丁进行分类或就分类达成一致，而是可以专注于对 IDLE 用户和未来 IDLE 开发最有利的事情。这也意味着 IDLE 补丁不一定必须分成“错误修复”更改和增强更改。

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

动机

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

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

对于上下文菜单，人们对添加内容的状态意见不一——是错误修复还是增强。即使是那些称其为增强的人，也对是否应该回溯补丁存在分歧。本 PEP 提议通过明确允许比其他标准库模块更宽松的回溯，使状态分歧变得无关紧要。

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]。）另一方面，在细节上浪费时间会耗费精力。如果一个 bug 的明显修复看起来像一个增强，那么编写一个单独的仅修复 bug 的补丁会增加工作量。而且，使代码在不同版本之间出现分歧会使未来的多版本补丁更加困难。

这些问题由搜索替换对话框说明。它曾经对某些用户输入引发异常[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)。它应该在确定第一个补丁不需要恢复时应用。

参考资料

版权

本文档已置于公共领域。