PEP 543

PEP 543 为 Python 定义了一个新的 TLS API，该 API 将通过使 Python 应用程序能够访问 Windows 和 macOS 上的原生 TLS 实现（而不是使用 OpenSSL）来增强 Python 的安全性。一个副作用是它允许访问系统信任存储和系统管理员在本地安装的证书，使 Python 应用程序能够使用“公司证书”而无需修改每个应用程序，从而正确验证 TLS 证书（而不是必须忽略或绕过 TLS 证书验证）。

出于实际原因，Cory Benfield 希望首先为 PEP 543 实现一个类似于 ssl.MemoryBIO 和 ssl.SSLObject 的无 I/O 类，并提供一个基于第一个类的第二个类来使用套接字或文件描述符。此设计将有助于构建代码以支持更多后端并简化测试和审计以及实现。稍后，可以使用直接套接字或文件描述符的优化类来提高性能。

虽然 PEP 543 定义了一个 API，但 PEP 只有在至少提供一个完整且良好的实现时才有意义。第一个实现理想情况下应基于 Python 标准库的 ssl 模块，因为默认情况下此模块会提供给所有用户，并且可以在没有其他更目标化的实现的情况下用作后备实现。

如果不执行此反向移植，则唯一可使用的基线实现将是 pyOpenSSL。但是，由于与 pip 的交互，这存在问题，pip 在所有受支持的版本上都与 CPython 一起提供。

requests、pip 和 ensurepip

目前正在计划将 Requests 迁移到更基于事件循环的模型。Requests 团队目前认为无法放弃对 Python 2.7 的支持，因此这样做需要使用 Twisted 或 Tornado，或者编写他们自己的异步抽象。

对于异步代码，MemoryBIO 与使用包装的套接字相比提供了巨大的优势。它减少了必须执行的缓冲量，适用于基于 IOCP 的反应器以及基于 select/poll 的反应器，并且还大大简化了反应器和实现代码。因此，Requests 不倾向于使用基于包装套接字的实现。在没有反向移植到 Python 2.7 的情况下，Requests 必须使用 Twisted 使用的相同解决方案：即，对 pyOpenSSL 的强制依赖关系。

出于实际原因，pip 程序必须嵌入其所有依赖项：即，它不能依赖于任何其他安装方法的存在。由于 pip 依赖于 requests，这意味着它必须嵌入 pyOpenSSL 的副本。这将意味着在安装 pip 时会遇到很大的可用性问题。目前，pip 不支持嵌入必须在每个平台上编译的 C 扩展，因此需要 C 编译器。

从 Python 2.7.9 开始，Python 既嵌入 pip 的副本以进行默认安装，也通过新的 ensurepip 模块在虚拟环境中使用。如果 pip 最终捆绑 PyOpenSSL，则 CPython 最终将捆绑 PyOpenSSL。只有反向移植 ssl.MemoryBIO 和 ssl.SSLObject 才能避免嵌入 pyOpenSSL 的需要，并解决引导问题（python -> ensurepip -> pip -> requests -> MemoryBIO）。

这种情况不如采用 PEP 543 的障碍那么成问题，因为很自然地，Requests 不必在放弃对 Python 2.7 的支持之前就迁移到事件循环模型。但是，只要它继续支持 Python 2，它就会使 Requests（和 pip）难以同时使用 asyncio 以及 async 和 await 关键字。

其他益处

采用此 PEP 将带来其他较小的生态系统益处。例如，Twisted 将能够减少其对第三方 C 扩展的依赖。此外，PyOpenSSL 开发团队希望停止维护该模块，此反向移植将使他们能够以优雅的方式做到这一点，而不会让用户陷入困境。

这些边缘效益虽然很小，但也为更广泛的 Python 生态系统提供了价值。

旧版 Python 2 怎么办？

世界上的一些 Python 2 用户没有跟上 Python 2 版本的发布。这通常是因为他们使用的是 LTS 版本，这些版本没有跟上 Python 2 的次要版本发布。这些用户将无法使用 MemoryBIO，因此关注 Python 2 兼容性的项目可能无法依赖于大多数用户系统上存在 MemoryBIO。

这种担忧是合理的。其重要性取决于当前 Python 2 用户迁移到 Python 3 的可能性，或者只是尝试使用最新的 Python 2 版本。换句话说，在某些时候，库将希望放弃对 Python 2 的支持：问题只是在他们这样做之前，其 Python 2 用户中的绝大多数是否已迁移到包含此反向移植的任何 Python 2 版本。

最终，此 PEP 的作者认为，此反向移植的负担足够小，即使考虑到此担忧，也足以证明反向移植是合理的。如果事实证明迁移到较新的 2.7 版本太慢，那么这项工作的价值将很小，但如果迁移到较新的 2.7 版本是合理的，那么将获得很大的价值。