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