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