(original) (raw)


On Jun 1, 2017, at 1:09 PM, Barry Warsaw <barry@python.org> wrote:

On Jun 02, 2017, at 02:14 AM, Chris Angelico wrote:

But it also includes people on stable Linux distros, where they have
automatic updates provided by Red Hat or Debian or whomever, so a change like
this WILL propagate - particularly (a) as the window is three entire years,
and (b) if the change is considered important by the distro managers, which
is a smaller group of people to convince than the users themselves.
\[...\]
So I'd be in the "yes" category. Across the next few years, I strongly
suspect that 2.7.14 will propagate reasonably well.

I'm not so sure about that, given long term support releases. For Ubuntu, LTS
releases live for 5 years:

https://www.ubuntu.com/info/release-end-of-life

By 2020, only Ubuntu 16.04 and 18.04 will still be maintained, so while 18.04
will likely contain whatever the latest 2.7 is available at that time, 16.04
won't track upstream point releases, but instead will get select cherry
picks. For good reason, there's a lot of overhead to backporting fixes into
stable releases, and something as big as being suggested here would, in my
best guess, have a very low chance of showing up in stable releases.



Using 2.7.9 as a sort of benchmark here, currently 26% of downloads from PyPI are using a version of Python older than 2.7.9, 2 months ago that number was 31%. (That’s total across all Python versions). Python >= 2.7.9, <3 is at 43% (previously 53%).

So in \~2.5 years 2.7.9+ has become > 50% of all downloads from PyPI while older versions of Python 2.7 are down to only \~25% of the total number of downloads made by pip. I was also curious about how this had changed over the past year instead of just the past two months, a year ago >=2.7,<2.7.9 accounted for almost 50% of all downloads from PyPI (compared to the 25% today). It \*looks\* like on average we’re dropping somewhere between 1.5% and 2% each month so a conservative estimate if these numbers hold, we’re be looking at single digit numbers for >=2.7,<2.7.9 in roughly 11 months, or 3.5 years after the release of 2.7.9.

If we assume that the hypothetical 2.7.14 w/ MemoryBio support would follow a similar adoption curve, we would expect to be able to mandate it for pip/etc in at a worst case scenario, 3-4 years after release.

In addition to that, pip 9 comes with a new feature that makes it easier to sunset support for versions of Python without breaking the world \[1\]. The likely scenario is that while pip 9+ is increasing in share Python <2.7.14 will be decreasing, and that would mean that we could \*likely\* start mandating it earlier, maybe at the 2 year mark or so.


\[1\] An astute reader might ask, why could you not use this same mechanism to simply move on to only supporting Python 3? It’s true we could do that, however as a rule we generally try to keep support for Pythons until the usage drops below some threshold, where that threshold varies based on how hard it is to continue supporting that version of Python and what the “win” is in terms of dropping it. Since we’re still at 90% of downloads from PyPI being done using Python 2, that suggests the threshold for Python 3.x is very far away and will extend beyond 2020 (I mean, we’re just \*now\* finally able to drop support for Python 2.6).

In case it’s not obvious, I am very much in support of this PEP.

—
Donald Stufft