将包标记为临时

包将通过其文档页面和文档字符串中的通知标记为临时。以下段落将作为注释添加到文档页面的顶部：

<X> 包已暂时包含在标准库中。如果核心开发人员认为有必要，可能会发生不向后兼容的更改（包括移除包）。

短语“临时基础”将是词汇表术语“临时包”的链接，定义为：

临时包是指已明确排除在标准库向后兼容性保证之外的包。虽然预计此类包不会发生重大更改，但只要它们被标记为临时，如果核心开发人员认为有必要，就可能会发生不向后兼容的更改（包括移除包）。此类更改不会无故进行——只有在发现包含包之前遗漏的严重缺陷时才会发生。

此过程允许标准库随着时间的推移不断发展，而不会将有问题的设计错误锁定很长一段时间。有关更多详细信息，请参阅 PEP 411。

以下内容将添加到包文档字符串的开头：

此包的 API 目前是临时的。有关详细信息，请参阅文档。

将包从临时状态移动到稳定状态，仅仅意味着从其文档页面和文档字符串中删除这些注释。

哪些包应该经历临时状态

我们期望大多数提议添加到 Python 标准库中的包，都会经历一个临时状态的功能发布。然而，可能存在一些例外，例如使用预定义 API 的包（例如 lzma，它通常遵循现有 bz2 包的 API），或者其 API 在 Python 开发社区中被广泛接受的包。

无论如何，提议添加到标准库中的包，无论是通过临时状态还是直接添加，都必须满足 PEP 2 设定的接受条件。

“毕业”标准

原则上，大多数临时包最终都应该毕业为稳定的标准库。不毕业的一些原因是：

• 该包可能被证明不稳定或脆弱，没有足够的开发人员支持来维护它。
• 在预览发布期间，可能会找到更好的替代包。

本质上，核心开发人员将根据具体情况做出决定。这里要强调的一点是，在某个发布中将包作为“临时”包含在标准库中，并不保证它在下一个发布中仍然是 Python 的一部分。同时，在临时包中进行更改的门槛相当高。我们预计大多数临时包的大部分 API 在毕业时将保持不变。预计撤回会很少见。

对核心开发团队的好处

目前，核心开发人员非常不愿向标准库添加新接口。这是因为一旦它们在发布中发布，由于向后兼容性问题，API 设计错误就会被锁定。

通过在整个发布期间，通过某种临时机制来管理所有主要的 API 添加，我们可以在将 API 与我们的标准向后兼容性保证锁定之前，获得一个完整的发布周期内的社区反馈。

我们还可以及早开始将临时包与标准库的其余部分集成，只要我们向打包者明确指出，临时包不应被视为可选的。临时 API 与标准库其余部分之间的唯一区别是，临时 API 明确不受通常的向后兼容性保证的约束。

对最终用户的好处

对于未来的最终用户而言，最广泛的好处在于更好的“开箱即用”体验——而不是被告知“哦，用于任务 X 的标准库工具很糟糕，请改用此第三方库”，这些更优秀的工具更有可能只需一个 import 即可使用。

对于开发人员需要对其上游依赖项进行尽职调查的环境（严重损害 PyPI 上大部分材料的成本效益，甚至完全排除），主要好处在于确保临时状态下的所有包至少从以下几个方面明确受 python-dev 的监管：

• 许可：由 PSF 根据贡献者许可协议重新分发。
• 文档：包的文档通过标准 Python 文档工具发布和组织（即 ReST 源，使用 Sphinx 生成输出并发布到 https://docs.pythonlang.cn）。
• 测试：包测试套件在 python.org buildbot 集群上运行，结果通过 https://pythonlang.cn/dev/buildbot 发布。
• 问题管理：错误和功能请求在 http://bugs.python.org 上处理。
• 源代码控制：软件的主存储库发布在 http://hg.python.org 上。