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

Nick Coghlan ncoghlan at gmail.com
Fri Jun 9 06:43:16 EDT 2017

On 9 June 2017 at 05:51, Donald Stufft <donald at stufft.io> wrote:

And the downside here is pretty small honestly?

Unfortunately, one of the downsides is "Doesn't provide any clearly compelling benefits to users of LTS distributions, so even those of us in a position to advocate for such backports probably won't win the related arguments".

So the question is whether or not we're OK with saying that users affected by that will need to switch to a different set of Python binaries to get the latest pip & requests (e.g. upgrading their base distro, or else adopting Red Hat SCLs or one of the cross-platform, and hence cross-distro, distributions).

It’s not changing behavior of anything that currently exists since it’s adding a new thing inside the ssl module and Alex has already written the patch so there’s little extra work to do and it actually makes maintenance easier since patches can more readily be applied straight from master.

The primary argument I can see against it, is one of purity, that 2.7 shouldn’t get new features but as we know, practicality beats purity ;) (and we’ve already accepted that TLS is a special case, special enough to break the rules, so the main question is whether this specific thing is worthwhile— which given it’s benefits to the Python ecosystem and to maintaining Python, I think it is).

It isn't a purity argument so much as a "Will the change reach a sufficiently large proportion of 2.7 users to actually solve the compatibility problem it is aiming to solve?" argument (There's a bit of a purity argument behind that, in that the PEP 466 backport did break customer applications due to the incompatibilities with some of the async frameworks that were using underscore prefixed APIs that changed behaviour, so our credibility for "trust us, it won't break anything" is low in this context, but it's not the primary objection)

I'm 100% confident that we'd reach a large enough audience with a compatibility shim that gets installed on disk as something other than "ssl" (e.g. "backport.ssl" or "_ssl_bootstrap"), and that has the virtue of enabling a multi-tiered distribution approach:

This approach also allows the API to be updated as necessary to meet the needs of PEP 543, without needing to go through the full PEP process again. The downside is adding a 3rd stack to maintain (Py3, Py2-compatible Py3 backport, Py2) without making maintenance on the Py2 stack any easier.

I'm markedly less confident of reaching a sufficiently large audience with a "So stop using the system Python, then" approach (Don't get me wrong, I'd love for people to stop using the system Python for things that aren't part of the operating system, but people also really like the convenience of doing that).

OTOH, if the aim is to make the change now, so it gets into Ubuntu 18.04, with a view to projects only starting to fully rely on it in mid-to-late 2018 or so? That timeline might actually work, and this approach has the benefit of actually making the Py2 SSL stack easier to maintain between now and 2020.

So honestly, I'd be +1 for either approach:

Cheers, Nick.

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

More information about the Python-Dev mailing list