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

[Bennet Fauber]

Thanks, Ralf.

Yes, I get that there are good reasons for wanting it both ways and
that is not possible.

That's why I asked whether something like an LTS had ever been
considered, which might make it possible for both sides to be happier.

In the end, if development outpaces users's ability to update, they
will keep using old versions and SciPy/NumPy will move on without
those people until they can update.

Whatever you choose, thanks for all the hard work you folks put into
this.  Computing is a better place for it.


On Sun, Aug 16, 2020 at 11:03 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
>
> On Sun, Aug 16, 2020 at 2:23 PM Bennet Fauber <bennet at umich.edu> 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.
>>
>> If there were a way to provide _only_ actual bug fixes for some
>> versions longer, a la the LTS releases of some Linux distributions,
>> that might be of benefit to users and would reduce the support burden
>> on developers who would not need to worry about fitting new features
>> into the older framework.
>>
>> All of that is not to say that you should not continue with current
>> deprecation plans.  Just to be sure that these concerns were voiced at
>> least once.  I hope that this perspective is of some use in your
>> considerations.
>
>
> Thanks for your thoughts Bennet. All of this was brought up in the NEP 29 discussion which recommended timelines for Python and NumPy version support. I don't think any of it is specific to SciPy. It's a trade-off: users may want perfect stability and updates for whatever version they're on for as long as possible, but that comes at the cost of making maintainers doing tedious work, like more release effort and figuring out why CI fails on some particular combination of old Python and NumPy versions. That tedious work then reduces the amount of time for tackling more relevant bugs and adding new features, and it likely also reduces total effort spent by maintainers over time (most people do this voluntarily, so motivation comes partly from enjoying to contribute).
>
> Cheers,
> Ralf
>
>
>>
>> Thanks for all the software, regardless!
>>
>>
>> On Sat, Aug 15, 2020 at 6:48 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > Python 3.9 is coming out before the next SciPy release, and NEP 29 recommends to support only Python >=3.7 and NumPy >= 1.16 from last month onwards [1]. I think supporting 3 Python versions and 5 NumPy versions in SciPy 1.6.0 is easily enough. That would also bring us back in line with SciPy on conda-forge, which built against NumPy 1.16 for 1.5.2.
>> >
>> > Any objections?
>> >
>> > Cheers,
>> > Ralf
>> >
>> > [1] https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev