On Thu, Nov 9, 2017 at 12:15 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Nov 8, 2017 16:51, "Matthew Brett" <matthew.br...@gmail.com> wrote: > > Hi, > > On Wed, Nov 8, 2017 at 7:08 PM, Julian Taylor > <jtaylor.deb...@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.har...@gmail.com <mailto:charlesr.har...@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 Windows-only-3.x-only. 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. Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
