[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Jun 5 07:00:25 EDT 2017

On 5 June 2017 at 18:42, Cory Benfield <cory at lukasa.co.uk> wrote:

On 3 Jun 2017, at 07:25, Nick Coghlan <ncoghlan at gmail.com> wrote: As a result, as awkward and annoying as it would be, I'm wondering if the structure of the requests migration may need to be something like:

- switch unconditionally to an async backend on Py3 - switch conditionally to an async backend on Py2 when PyOpenSSL is available - retain sufficient sync-only support on Py2 to allow pip to disable the PyOpenSSL dependency Ultimately we don’t have the resources to do this. The requests core development team is 4 people, 3 of whom are part time best-effort maintainers and one of whom is me, who has foolishly decided to also work on PEP 543 as well as take over the lead maintenance role on urllib3. urllib3 has another two additional best-effort maintainers. We simply do not have the development resources to support two parallel branches of code. Even if we did, doing so is a recipe for adding bugs and inconsistencies between the two, leading to increased workload as we break our users and fail to keep the two branches in sync. It also makes it much harder for users to migrate from our synchronous backend to our async one, as those two no longer use identical underlying implementations and so will have subtle inconsistencies. The TL;DR there is: no, we’d rather stay sync only than do that.

Would you be OK with the notion of a "just for pip bootstrapping" private backend in _ensurepip_ssl?

That is, the only officially supported async-backed requests configuration on Py2 would be with the PyOpenSSL dependency installed, but in collaboration with the pip devs we'd also plumb in the pieces to let a new async-backed requests work without any extension modules other than those in the standard library.

That way, the only thing truly gated on the backport would be pip updating its bundled version of requests to the async-backed version - for normal third party use, the change would be "you need PyOpenSSL", rather than "you need a newer version of Python".

We'd still effectively end up with two different code execution paths (one backed by PyOpenSSL, one backed by the new private _ensurepip_ssl extension module), but the level of divergence would be much lower (it's just a question of where MemoryBIO and SSLObject are coming from) and the support scope for the less frequently used path would be much narrower (i.e. if a problem report isn't related to pip bootstrapping, it can be closed as "won't fix")

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list