[Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

Ralf Gommers ralf.gommers at gmail.com
Thu Nov 9 02:57:02 EST 2017

On Thu, Nov 9, 2017 at 12:15 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Nov 8, 2017 16:51, "Matthew Brett" <matthew.brett at gmail.com> wrote:
> Hi,
> On Wed, Nov 8, 2017 at 7:08 PM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
> > On 06.11.2017 11:10, Ralf Gommers wrote:
> >>
> >>
> >> On Mon, Nov 6, 2017 at 7:25 AM, Charles R Harris
> >> <charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>> wrote:
> >>
> >>     Hi All,
> >>
> >>     Thought I'd toss this out there. I'm tending towards better sooner
> >>     than later in dropping Python 2.7 support as we are starting to run
> >>     up against places where we would like to use Python 3 features. That
> >>     is particularly true on Windows where the 2.7 compiler is really old
> >>     and lacks C99 compatibility.
> >>
> >>
> >> This is probably the most pressing reason to drop 2.7 support. We seem
> >> to be expending a lot of effort lately on this stuff. I was previously
> >> advocating being more conservative than the timeline you now propose,
> >> but this is the pain point that I think gets me over the line.
> >
> >
> > Would dropping python2 support for windows earlier than the other
> > platforms a reasonable approach?
> > I am not a big fan of to dropping python2 support before 2020, but I
> > have no issue with dropping python2 support on windows earlier as it is
> > our largest pain point.
> I wonder about this too.  I can imagine there are a reasonable number
> of people using older Linux distributions on which they cannot upgrade
> to a recent Python 3,
> My impression is that this is increasingly rare, actually. I believe RHEL
> is still shipping 2.6 by default, which we've already dropped support for,
> and if you want RH python then they provide supported 2.7 and 3.latest
> through exactly the same channels. Ubuntu 14.04 is end-of-life in April
> 2019, so pretty irrelevant if we're talking about 2019 for dropping
> support, and 16.04 ships with 3.5. Plus with docker, conda, PPAs, etc.,
> getting a recent python is easier than its ever been.
> > but
> is that likely to be true for Windows?
> We'd have to make sure we could persuade pypi to give the older
> version for Windows, by default - I don't know if that is possible.
> Currently it's not – if pip doesn't see a Windows wheel, it'll try
> downloading and building an sdist. There's a mechanism for sdists to
> declare what version of python they support but (thanks to the jupyter
> folks for implementing this), but that's all. The effect is that if we
> release a version that drops support for py2 entirely, then 'pip install'
> on py2 will continue to work and give the last supported version, but if we
> release a version that drops py2 on Windows but keeps it on other platforms
> then 'pip install' on py2 on Windows will just stop working entirely.
> This is possible to fix – it's just software – but I'm not volunteering...

Given the release cycle of pip (slow) and the bandwidth required to
implement this, I think that this is likely a showstopper for

Another consideration is that choices made by numpy tend to propagate to
the rest of the ecosystem, and support for Python versions that's
OS-independent is nicer than Windows special-casing.

And yet another is that when we do finally drop 2.7, I think we'd want to
get the full benefits of doing so. That's new 3.x features (@ in
particular), cleaning up lots of support code, etc.

For those reasons I think we should balance the pain and benefits of 2.7
support and just pick a date to drop it completely, not just on Windows.

Regarding http://www.python3statement.org/: I'd say that as long as there
are people who want to spend their energy on the LTS release (contributors
*and* enough maintainer power to review/merge/release), we should not
actively prevent them from doing that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20171109/c7d7bd15/attachment.html>

More information about the NumPy-Discussion mailing list