[Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

[Charles R Harris]

On Thu, Nov 9, 2017 at 11:24 AM, Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> Hi all,
>
> Apologies if this mail appear out of thread I just subscribed to respond.
>
> > Yeah, agreed. I don't feel like this is incompatible with the spirit of
> > python3statement.org, though looking at the text I can see how it's not
> clear.
> > My guess is they'd be happy to adjust the text, especially if it lets
> them add
> > numpy :-). CC'ing Thomas and Matthias.
>
> Happy to see NumPy at least having this conversation ! I agree with Thomas,
> we're pretty loose on what dropping support means; one of the main reason
> for
> the Python-3-Statement is communication to users and other project; and
> covey
> that there is a strong intent that you have until 2020 to get ready (if not
> before).
>
> The voice of NumPy have a huge weight in the balance.
>
> I quickly went through the thread and have a few responses:
>
> > NumPy (and to a lesser extent SciPy) is in a tough position being at the
> > bottom of many scientific Python programming stacks. Whenever you
> > drop Python 2 support is going to upset someone.
>
> And that is why you should decide of doing it at some point, and telling
> it to
> the world and the sooner you decide and advertise it (regardless of
> effective
> "deadline" the better.
>
> The Scientific Python is in a catch 22 position; Most of the ecosystem
> will not
> drop 2.7 because "numpy is still compatible python 2.7", and numpy does
> not drop
> it because "many packages rely on numpy support for 2.7".
>
>
> > 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.
>
> I don't think there is, though  if you tag a release with
> `requires_python>3.3`,
> then pip 9+ users on python 2.7 will not even realise there are new release
> compatible only with 3.3+.
>
> Technically you can make numpy a meta-package that requires numpy-27 on
> windows
> only... but it has its own drawbacks.
>
> > 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.
>
> > 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.
>
> These two are _in practice_ against each other; if you do major cleaning
> then
> most backports will have a hard time being auto applied (just a warning).
> If you
> have a team that want to do a LTS I would suggest "cleaning" only when you
> are
> actually touching some code and the python-2 support code is in the way.
> not
> cleaning "for the sake of cleaning" at least until the 2 code base are far
> enough.
>
> We have a bot on Jupyter/Matplotlib that help to backport PRs to older
> branches.
> I'm happy to open it to the numpy org if it helps.
>
> > It is too ambitious to pledge to drop support for Python 2.7 no later
> than
> > 2020, coinciding with the Python development team’s timeline for dropping
> > support for Python 2.7?
>
> The hardest part is communication. And not just "We're dropping in 2020"
> but
> also "We still care about you, 2.7 users", ans especially tell 2.7 users
> and old
> pip users how to correctly pip their dependency on numpy (to still get
> LTS if LTS
> there is)
>
> One more thing, there is a lot of of discussion about a "Volonteer LTS",
> you may
> also want to consider a partnership with a company for an officially
> recommended
> commercial offer.
>
>
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).

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20171109/985ef3d2/attachment.html>