[Numpy-discussion] Long term plans for dropping Python 2.7

[Nathaniel Smith]

On Fri, Apr 14, 2017 at 5:19 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> Hi All,
>
> It may be early to discuss dropping support for Python 2.7, but there is a
> disturbance in the force that suggests that it might be worth looking
> forward to the year 2020 when Python itself will drop support for 2.7. There
> is also a website, http://www.python3statement.org, where several projects
> in the scientific python stack have pledged to be Python 2.7 free by that
> date.  Given that, a preliminary discussion of the subject might be
> interesting, if only to gather information of where the community currently
> stands.

One reasonable position would that numpy releases that happen while
2.7 is supported upstream will also support 2.7, and releases after
that won't.

>From numpy's perspective, I feel like the most important reason to
continue supporting 2.7 is our ability to convince people to keep
upgrading. (Not the only reason, but the most important.) What I mean
is: if we dropped 2.7 support tomorrow then it wouldn't actually make
numpy unavailable on python 2.7; it would just mean that lots of users
stayed at 1.12 indefinitely. Which is awkward, but it wouldn't be the
end of the world – numpy is mature software and 1.12 works pretty
well. The big problem IMO would be if this then meant that lots of
downstream projects felt that they had to continue supporting 1.12
going forward, which makes it very difficult for us to effectively
ship new features or even bug fixes – I mean, we can ship them, but
no-one will use them. And if a downstream project finds a bug in numpy
and can't upgrade numpy, then the tendency is to work around it
instead of reporting it upstream. I think this is the main thing we
want to avoid.

This kind of means that we're at the mercy of downstream projects,
though – if scipy/pandas/etc. decide they want to support 2.7 until
2022, it might be in our best interest to do the same. But there's a
collective action problem here: we want to keep supporting 2.7 so long
as they do, but at the same time they may feel they need to keep
supporting 2.7 as long as we do. And all of us would prefer to drop
2.7 support sooner rather than later, but we might all get stuck
because we're waiting for someone else to move first.

So my suggestion would be that numpy make some official announcement
that our plan is to drop support for python 2 immediately after
cpython upstream does. If worst comes to worst we can always decide to
extend it at the time... but if we make the announcement now, then
it's less likely that we'll need to :-).

Another interesting project to look at here is django, since they
occupy a similar place in the ecosystem (e.g. last I checked numpy and
django are the two most-imported python packages on github):
https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
Their approach isn't directly applicable, because unlike us they have
a strict time-based release schedule, defined support period for each
release, and a distinction between regular and long-term support
releases, where regular releases act sort of like
pre-releases-on-steroids for the next LTS release. But basically what
they settled on is philosophically similar to what I'm suggesting:
they don't want an LTS to be supporting 2.7 beyond when cpython is
supporting it. Then on top of that they don't want to support 2.7 in
the regular releases leading up to that LTS either, so the net effect
is that their last release with 2.7 support came out last week, and it
will be supported until 2020 :-). And another useful precedent I think
is that they announced this two years ago, back in 2015; if we make an
announcement now, we'll be be giving a similar amount of warning.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org