[SciPy-Dev] proposal to drop Python 3.6 and NumPy 1.14 / 1.15

[Evgeni Burovski]

No objections for bumping the minimum NumPy version.
For bumping the python version.. not quite an objection, more of a
suggestion to consider holding it back.
I guess there are three kinds of stakeholders here:
- for end users, upgrading the python version is a fairly major hassle.
Three versions of python now means three years back if they switch to a
12-months cadence. Three years of support is definitely on a low side of
things. (with my PI hat on, I can certainly relate to what Bennet was
saying, even if our lab has it way easier than others).
- for the scipy devs, what exactly drives us to drop it? For 3.5 it was of
course the matmul operator, for 3.6 it's f-strings, what's there in 3.7
which makes it not fun to stay on 3.6?
- for the RM and other packagers: how much of a hassle is it to keep an
older version? I realize it's more wheels to build for the scipy RM, but
that's fairly automated now?



Cheers,
Evgeni


On Sun, Aug 16, 2020 at 6:22 PM Matti Picus <matti.picus at gmail.com> wrote:
>
>
> On 8/16/20 4:23 PM, Bennet Fauber wrote:
> > This post is by way of trying to articulate some concerns from the end
> > user side of things.
> >
> > It looks like NumPy 19.1 supports Python 3.6.
> >
> >> This release supports Python 3.6-3.8. Cython >= 0.29.21 needs to be
used when building
> >> with Python 3.9 for testing purposes.
> > https://numpy.org/devdocs/release/1.19.1-notes.html
> >
> > The section of the release notes for NumPy 1.20.0 does not contain the
> > section at the top saying which versions of Python are supported.
> > (https://numpy.org/devdocs/release/1.20.0-notes.html)
> >
> > For Python itself,  I find on their releases, the 3.6.12 schedule was
> >
> >      3.6.12 final: 2020-08-14 (expected)
> > https://www.python.org/dev/peps/pep-0494/#id9
> >
> > but does not seem to have made it, and Python 3.6.11 was released June
> > 27, 2020.  The Python plans for 3.6.13 and beyond are Security fixes
> > only, as needed, until 2021-12.  That seems, from my user perspective,
> > a better date for deprecation and not too far from the just proposed
> > one.
> >
> > Acknowledging the additional burden of 'supporting' older versions of
> > Python, still it would seem that matching NumPy is not a bad thing.
> >
> >  From a strictly consumer perspective, where much of the work is
> > getting all of the non-NumPy and non-SciPy functionality to work and
> > be stable, upgrading Python can be very disruptive.  Time spent
> > getting the 'glue' around analytics to work is time we cannot spend on
> > science.  There are large projects that do keep up, but they tend also
> > to be funded well.  The many small labs on my campus do not have
> > funding for software development, are unlikely to ever get any, so any
> > work required to fix software because of updates comes from their
> > budget for science and from their scientists who are not as proficient
> > and therefore not as efficient at adapting to a newer version of
> > Python and all the reinstallation of libraries that attends it.
> >
>
> Is there a forum where we could explore the larger question around best
> practices in helping projects and teams keep their software up-to-date
> through rolling updates, test suites, and documentation? A few things
> come to mind:
>
> - developing a culture of version control and tests when creating
> software, even if it is grad students racing towards their degrees
>
> - freezing environments in images, which is a whole discipline unto
> itself, and needed for reproducible science
>
> - offloading the task of maintaining computing environments using things
> like Jupyter Hub or other web-based services
>
>
> FWIW, python is changing their release cadence from once every 18 months
> to once every 12 months[1] so it is likely this problem will get harder.
>
> Matti
>
> [1] https://www.python.org/dev/peps/pep-0602/#annual-release-cadence
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200817/52dcfc2a/attachment.html>