<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 15, 2017 at 7:02 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Apr 14, 2017 at 10:47 PM, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sat, Apr 15, 2017 at 5:19 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br>
</span>[...]<br>
<div><div class="m_-8913422161829130540h5">>> From numpy's perspective, I feel like the most important reason to<br>
>> continue supporting 2.7 is our ability to convince people to keep<br>
>> upgrading. (Not the only reason, but the most important.) What I mean<br>
>> is: if we dropped 2.7 support tomorrow then it wouldn't actually make<br>
>> numpy unavailable on python 2.7; it would just mean that lots of users<br>
>> stayed at 1.12 indefinitely. Which is awkward, but it wouldn't be the<br>
>> end of the world – numpy is mature software and 1.12 works pretty<br>
>> well. The big problem IMO would be if this then meant that lots of<br>
>> downstream projects felt that they had to continue supporting 1.12<br>
>> going forward, which makes it very difficult for us to effectively<br>
>> ship new features or even bug fixes – I mean, we can ship them, but<br>
>> no-one will use them. And if a downstream project finds a bug in numpy<br>
>> and can't upgrade numpy, then the tendency is to work around it<br>
>> instead of reporting it upstream. I think this is the main thing we<br>
>> want to avoid.<br>
><br>
><br>
> +1<br>
><br>
>><br>
>><br>
>> This kind of means that we're at the mercy of downstream projects,<br>
>> though – if scipy/pandas/etc. decide they want to support 2.7 until<br>
>> 2022, it might be in our best interest to do the same. But there's a<br>
>> collective action problem here: we want to keep supporting 2.7 so long<br>
>> as they do, but at the same time they may feel they need to keep<br>
>> supporting 2.7 as long as we do. And all of us would prefer to drop<br>
>> 2.7 support sooner rather than later, but we might all get stuck<br>
>><br>
>> because we're waiting for someone else to move first.<br>
><br>
><br>
> I don't quite agree about being stuck. These kind of upgrades should and<br>
> usually do go top of stack to bottom. Something like Jupyter which is mostly<br>
> an end user tool goes first (they announced 2020 quite a while ago), domain<br>
> specific packages go at a similar time, then scipy & co, and only after that<br>
> numpy. Cython will be even later I'm sure - it still supports Python 2.6.<br>
<br>
</div></div>To make sure we're on the same page about what "2020" means here: the<br>
latest release of IPython is 5.0, which came out in July last year.<br>
This is the last release that supports py2; they dropped support for<br>
py2 in master months ago, and 6.0 (whose schedule has been slipping,<br>
but I think should be out Any Time Now?) won't support py2. Their plan<br>
is to keep backporting bug fixes to 5.x until the end of 2017; after<br>
that the core team won't support py2 at all. And they've also<br>
announced that if volunteers want to step up to maintain 5.x after<br>
that, then they're willing to keep accepting pull requests until July<br>
2019.<br>
<br>
Refs:<br>
  <a href="https://blog.jupyter.org/2016/07/08/ipython-5-0-released/" rel="noreferrer" target="_blank">https://blog.jupyter.org/2016/<wbr>07/08/ipython-5-0-released/</a><br>
  <a href="https://github.com/jupyter/roadmap/blob/master/accepted/migration-to-python-3-only.md" rel="noreferrer" target="_blank">https://github.com/jupyter/roa<wbr>dmap/blob/master/accepted/migr<wbr>ation-to-python-3-only.md</a><br>
<br>
I suspect that in practice that "end of 2017" date will the<br>
end-of-support date for most intents and purposes. And for numpy with<br>
its vaguely defined support periods, I think it makes most sense to<br>
talk in terms of release dates;</blockquote><div><br></div><div>agreed, release dates makes sense. we don't want to be doing some kind of LTS scheme.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> so if we want to compare<br>
apples-to-apples, my suggestion is that numpy drops py2 support in<br>
2020 and in that sense ipython dropped py2 support in july last year.<br>
<span><br>
>><br>
>> So my suggestion would be that numpy make some official announcement<br>
>> that our plan is to drop support for python 2 immediately after<br>
>> cpython upstream does.<br>
><br>
><br>
> Not quite sure CPython schedule is relevant - important bug fixes haven't<br>
> been making it into 2.7 for a very long time now, so the only change is the<br>
> rare security patch.<br>
<br>
</span>Huh? 2.7 gets tons of changes: <a href="https://github.com/python/cpython/commits/2.7" rel="noreferrer" target="_blank">https://github.com/python/cpyt<wbr>hon/commits/2.7</a></blockquote><div><br></div><div>You're right. My experience is ending up on <a href="http://bugs.python.org">bugs.python.org</a> when debugging and the answer to "can this be backported to 2.7" usually being no - but it looks like my experience is skewed by distutils, which is not exactly well maintained.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Officially CPython has 2 modes for releases: "regular support" and<br>
"security fixes only". 2.7 is special – it get regular support, and<br>
then on top of that it also has a special exception to allow certain<br>
kinds of major changes, like the ssl module backports. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you know of important bug fixes that they're missing then I think<br>
they'd like to know :-). </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, the reason the CPython schedule is relevant is that once they<br>
drop support, it *will* stop getting security patches, so it will<br>
become increasingly impossible to use safely.<br></blockquote><div><br></div><div>For web stuff yes, but not all that relevant for scientific work.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
>><br>
>> If worst comes to worst we can always decide to<br>
>> extend it at the time... but if we make the announcement now, then<br>
>> it's less likely that we'll need to :-).<br>
><br>
><br>
> I'd be in favor of putting out a schedule in coordination with<br>
> scipy/pandas/etc, but it probably should look more like<br>
> - 2020: what's on <a href="http://www.python3statement.org/" rel="noreferrer" target="_blank">http://www.python3statement.or<wbr>g/</a> now<br>
> - 2021: scipy / pandas / scikit-learn / etc.<br>
<br>
</span>Um... pandas is already on <a href="http://python3statement.org" rel="noreferrer" target="_blank">python3statement.org</a> right now :-)<br>
<br>
> - 2022: numpy<br>
<br>
Honestly I don't see why we should plan to support python 2 a day<br>
longer than our major downstream dependencies. That was the point of<br>
my first paragraph: for us the main benefit to supporting 2 is to<br>
avoid forcing our downstream dependencies to pin an old numpy. What's<br>
that extra year get us if they've already moved on?<br>
<br>
The other odd thing about this schedule is that you're suggesting that<br>
the organizing principle should be that the stack switches from<br>
top-of-stack to bottom... but then you left out the bottom of the<br>
stack! :-)<br></blockquote><div><br></div><div>I don't think of Python as part of the stack, because it's not upgradeable for most users (except for with conda). It's more like having a base platform (OS + compilers + Python version) on which you install a scientific stack which has numpy as its lowest level component.<br><br></div><div>Ralf<br><br></div></div><br></div></div>