PEP 543

PEP 543 定義了一個新的 Python TLS 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 模組，因為該模組預設隨所有使用者分發，並且可以在沒有更具針對性的實現時用作備用實現。

如果未執行此 backport，唯一可用的基礎實現將是 pyOpenSSL。然而，這存在問題，因為它會與 pip 互動，而 pip 是隨所有受支援版本的 CPython 分發的。

requests, pip 和 ensurepip

目前有計劃研究將 Requests 遷移到更面向事件迴圈的模型。Requests 團隊目前不認為可以放棄對 Python 2.7 的支援，因此這樣做將需要使用 Twisted 或 Tornado，或者編寫自己的非同步抽象。

對於非同步程式碼，MemoryBIO 與使用包裝套接字相比具有顯著優勢。它減少了必須進行的緩衝量，可以在基於 IOCP 的反應器以及基於 select/poll 的反應器上工作，並且還大大簡化了反應器和實現程式碼。因此，Requests 不願使用基於包裝套接字實現的方案。在沒有 backport 到 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。只有 backport 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 開發團隊希望淘汰該模組，此 backport 將使他們能夠以一種優雅的方式做到這一點，而不會讓他們的使用者陷入困境。

所有這些零星的好處，雖然微小，但也為更廣泛的 Python 生態系統帶來了價值。

舊的 Python 2 怎麼辦？

世界上許多 Python 2 使用者跟不上 Python 2 的釋出節奏。這通常是因為他們使用的是未跟上 Python 2 次要版本釋出的 LTS 版本。這些使用者將無法使用 MemoryBIO，因此關注 Python 2 相容性的專案可能無法在他們的大多數使用者系統上依賴 MemoryBIO 的存在。

這種擔憂是合理的。它有多關鍵取決於當前 Python 2 使用者遷移到 Python 3 的可能性，或者他們只是嘗試使用最新版本的 Python 2。換句話說，總有一天庫會想要放棄 Python 2 支援：問題只在於，在他們放棄支援之前，他們的 Python 2 使用者中是否有很大一部分已經遷移到包含此 backport 的 Python 2 版本。

最終，此 PEP 的作者認為此 backport 的負擔足夠小，值得在考慮此擔憂後進行 backport。如果事實證明遷移到較新的 2.7 版本過於緩慢，那麼這項工作的價值將很小，但如果遷移到較新的 2.7 版本是合理的，那麼將獲得巨大的價值。