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

[Matthias Bussonnier]

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.

Thanks,
-- 
Matthias

On Thu, Nov 9, 2017 at 10:21 AM, Nathaniel Smith <njs at pobox.com> wrote:
> See Thomas's reply quoted below (it was rejected by the mailing list since
> he's not subscribed):
>
>
> On Nov 9, 2017 01:24, "Thomas Kluyver" <thomas at kluyver.me.uk> wrote:
>
> On Thu, Nov 9, 2017, at 08:52 AM, Nathaniel Smith wrote:
>
> On Nov 8, 2017 23:59, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>
> 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.
>
>
> 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.
>
>
> Thanks Nathaniel. We have (IMO) left a degree of deliberate ambiguity around
> precisely what 'drop support' means, because it's not going to be the same
> for all projects. The nature of open source also means that there can be
> ambiguity over what 'support' entails and who is considered part of the
> project.
>
> I would say that the idea of the statement is compatible with an LTS release
> series receiving critical bugfixes beyond 2020, while the main energy of the
> project is focused on Py3-only feature releases.
>
> [If numpy-discussion doesn't allow non-member posts, feel free to pass this
> on or quote it in on-list messages]
>
> Thomas
>
>