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

[Matti Picus]

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