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

[Charles R Harris]

On Fri, Apr 14, 2017 at 11:47 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

>
>
> On Sat, Apr 15, 2017 at 5:19 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> 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.
>>
>
> +1
>
>
>>
>> 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.
>>
>
> I don't quite agree about being stuck. These kind of upgrades should and
> usually do go top of stack to bottom. Something like Jupyter which is
> mostly an end user tool goes first (they announced 2020 quite a while ago),
> domain specific packages go at a similar time, then scipy & co, and only
> after that numpy. Cython will be even later I'm sure - it still supports
> Python 2.6.
>
>
>>
>> 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.
>
>
> Not quite sure CPython schedule is relevant - important bug fixes haven't
> been making it into 2.7 for a very long time now, so the only change is the
> rare security patch.
>
>
>> 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 :-).
>>
>
> I'd be in favor of putting out a schedule in coordination with
> scipy/pandas/etc, but it probably should look more like
> - 2020: what's on http://www.python3statement.org/ now
> - 2021: scipy / pandas / scikit-learn / etc.
> - 2022: numpy
>
>

I think things will move faster than one might think. In any case, we are
probably about 5 releases away from 2020. As Nathaniel points out, numpy is
mature and 1.12 is pretty good already, so hopefully 1.17 would be even
better. I think dropping Python 2.7 support at that point would not cause
much in the way of problems as 1.17 should be good for a number of years
after that and would be easily installed from PyPI.

A bigger driver long term might be uptake by distros, although the impact
of that might be harder to estimate. I suspect it will affect developers
more than end users, who will more likely be using Anaconda, Canopy, or
similar to manage their development environment.

Another thing to consider is that future developers will likely have less
and less experience with Python 2.7 as teaching and classroom use moves to
3.

Whatever we decide, I think Nathaniel's point about making an early
announcement is a good one, as is Julian's comment about bringing Numpy
into full support of Python 3. We need to put together a plan with at least
a tentative schedule that will help get downstream projects thinking about
their own plans and engender more feedback.

It might be useful to have a BOF(s) at SciPy 2017 where the issue can be
discussed with a broader range of people.

<snip>

Chuck


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