<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 9, 2017 at 11:24 AM, Matthias Bussonnier <span dir="ltr"><<a href="mailto:bussonniermatthias@gmail.com" target="_blank">bussonniermatthias@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Apologies if this mail appear out of thread I just subscribed to respond.<br>
<span class=""><br>
> Yeah, agreed. I don't feel like this is incompatible with the spirit of<br>
> <a href="http://python3statement.org" rel="noreferrer" target="_blank">python3statement.org</a>, though looking at the text I can see how it's not clear.<br>
> My guess is they'd be happy to adjust the text, especially if it lets them add<br>
> numpy :-). CC'ing Thomas and Matthias.<br>
<br>
</span>Happy to see NumPy at least having this conversation ! I agree with Thomas,<br>
we're pretty loose on what dropping support means; one of the main reason for<br>
the Python-3-Statement is communication to users and other project; and covey<br>
that there is a strong intent that you have until 2020 to get ready (if not<br>
before).<br>
<br>
The voice of NumPy have a huge weight in the balance.<br>
<br>
I quickly went through the thread and have a few responses:<br>
<span class=""><br>
> NumPy (and to a lesser extent SciPy) is in a tough position being at the<br>
> bottom of many scientific Python programming stacks. Whenever you<br>
> drop Python 2 support is going to upset someone.<br>
<br>
</span>And that is why you should decide of doing it at some point, and telling it to<br>
the world and the sooner you decide and advertise it (regardless of effective<br>
"deadline" the better.<br>
<br>
The Scientific Python is in a catch 22 position; Most of the ecosystem will not<br>
drop 2.7 because "numpy is still compatible python 2.7", and numpy does not drop<br>
it because "many packages rely on numpy support for 2.7".<br>
<span class=""><br>
<br>
> We'd have to make sure we could persuade pypi to give the older<br>
> version for Windows, by default - I don't know if that is possible.<br>
<br>
</span>I don't think there is, though  if you tag a release with `requires_python>3.3`,<br>
then pip 9+ users on python 2.7 will not even realise there are new release<br>
compatible only with 3.3+.<br>
<br>
Technically you can make numpy a meta-package that requires numpy-27 on windows<br>
only... but it has its own drawbacks.<br>
<span class=""><br>
> And yet another is that when we do finally drop 2.7, I think we'd want to<br>
> get the full benefits of doing so. That's new 3.x features (@ in<br>
> particular), cleaning up lots of support code, etc.<br>
<br>
</span><span class="">> Regarding <a href="http://www.python3statement.org/" rel="noreferrer" target="_blank">http://www.python3statement.<wbr>org/</a>: I'd say that as long as there<br>
> are people who want to spend their energy on the LTS release (contributors<br>
> *and* enough maintainer power to review/merge/release), we should not<br>
> actively prevent them from doing that.<br>
<br>
</span>These two are _in practice_ against each other; if you do major cleaning then<br>
most backports will have a hard time being auto applied (just a warning). If you<br>
have a team that want to do a LTS I would suggest "cleaning" only when you are<br>
actually touching some code and the python-2 support code is in the way. not<br>
cleaning "for the sake of cleaning" at least until the 2 code base are far<br>
enough.<br>
<br>
We have a bot on Jupyter/Matplotlib that help to backport PRs to older branches.<br>
I'm happy to open it to the numpy org if it helps.<br>
<span class=""><br>
> It is too ambitious to pledge to drop support for Python 2.7 no later than<br>
> 2020, coinciding with the Python development team’s timeline for dropping<br>
> support for Python 2.7?<br>
<br>
</span>The hardest part is communication. And not just "We're dropping in 2020" but<br>
also "We still care about you, 2.7 users", ans especially tell 2.7 users and old<br>
pip users how to correctly pip their dependency on numpy (to still get<br>
LTS if LTS<br>
there is)<br>
<br>
One more thing, there is a lot of of discussion about a "Volonteer LTS", you may<br>
also want to consider a partnership with a company for an officially recommended<br>
commercial offer.<br>
<br></blockquote><div><br></div><div>One thing worth considering might be making the release that drops 2.7 NumPy 2.0 just so that there is a clear break point. Then if someone wants to continue the 1.x line of releases supporting 2.7 they can do so. ISTR that git now has some features that might aid in that. If the `requires` bit works well with pip then we can also share the same pip page (maybe).</div><div><br></div><div><snip></div><div><br></div><div>Chuck </div></div></div></div>