[Numpy-discussion] Proposal of timeline for dropping Python 2.7 support
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:
> 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...
More information about the NumPy-Discussion