[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

Cory Benfield cory at lukasa.co.uk
Thu Jun 1 06:22:21 EDT 2017

> On 1 Jun 2017, at 10:23, Antoine Pitrou <antoine at python.org> wrote:
> Yes, I disagree.  We needn't backport that new API to Python 2.7.
> Perhaps it's time to be reasonable: Python 2.7 has been in bugfix-only
> mode for a very long time.  Python 3.6 is out.  We should move on.

Who is the “we” that should move on? Python core dev? Or the Python ecosystem? Because if it’s the latter, then I’m going to tell you right now that the ecosystem did not get the memo. If you check the pip download numbers for Requests in the last month you’ll see that 80% of our downloads (9.4 million) come from Python 2. That is an enormous proportion: far too many to consider not supporting that user-base. So Requests is basically bound to support that userbase.

Requests is stuck in a place from which it cannot move. We feel we cannot drop 2.7 support. We want to support as many TLS backends as possible. We want to enable the pip developers to focus on their features, rather than worrying about HTTP and TLS. And we want people to adopt the async/await keywords as much as possible. It turns out that we cannot satisfy all of those desires with the status quo, so we proposed an alternative that involves backporting MemoryBIO.

So, to the notion of “we need to move on”, I say this: we’re trying. We really, genuinely, are. I don’t know how much stronger of a signal I can give about how much Requests cares about Python 3 than to signal that we’re trying to adopt async/await and be compatible with asyncio. I believe that Python 3 is the present and future of this language. But right now, we can’t properly adopt it because we have a userbase that you want to leave behind, and we don’t.

I want to move on, but I want to bring that 80% of our userbase with us when we do. My reading of your post is that you would rather Requests not adopt the async/await paradigm than backport MemoryBIO: is my understanding correct? If so, fair enough. If not, I’d like to try to work with you to a place where we can all get what we want.


More information about the Python-Dev mailing list