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

[Ralf Gommers]

On Wed, Nov 11, 2020 at 10:17 PM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> Time to follow up here I think. At the moment, our wheels repo weekly cron
> job for POSIX systems includes multiple Python 3.6 matrix entries and they
> all build/pass tests:
> https://travis-ci.com/github/MacPython/scipy-wheels/builds/199857636
>
> This means a few things:
> 1) Obviously, we have not yet turned off support for Python 3.6 in the
> master branch yet
> 2) At the moment, Python 3.6 does not appear to be causing problems
>
> Of course, just because there are no problems with 3.6 now does not mean
> that there won't be problems when backporting later as master branch
> evolves.
>
> Is the final decision here to turn off 3.6 support before we branch for
> 1.6.x series?
>

Yes, we should. Timing of this conversation was a bit unfortunate for me,
so I didn't get around to opening a PR in September. I can do so tomorrow.

Cheers,
Ralf



> Best wishes,
> Tyler
>
> On Fri, 11 Sep 2020 at 15:42, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>>
>>
>> On Mon, Aug 24, 2020 at 10:47 PM Warren Weckesser <
>> warren.weckesser at gmail.com> wrote:
>>
>>> Sorry for the top post, but this question doesn't follow immediately
>>> from any previous comment.
>>>
>>> Is the conclusion of this thread that with SciPy 1.6 we will
>>> definitely drop Python 3.6 support?
>>
>>
>> I think so. Given that there were a few hesitations at least, I'll split
>> it in separate PRs - will do the NumPy one first.
>>
>> It might be useful to use
>>> dataclasses (https://docs.python.org/3/library/dataclasses.html), and
>>> they are new in Python 3.7.
>>>
>>
>> You want to start using them now, or is it more a "nice to have the
>> option"?
>>
>> Cheers,
>> Ralf
>>
>>
>>> Warren
>>>
>>>
>>> On 8/20/20, Charles R Harris <charlesr.harris at gmail.com> wrote:
>>> > On Sun, Aug 16, 2020 at 5:17 PM Ilhan Polat <ilhanpolat at gmail.com>
>>> wrote:
>>> >
>>> >> I have too many personas in my head arguing about this. And many of
>>> them
>>> >> are in conflict.
>>> >>
>>> >> 1- I think I had enough arguments online to be known as buying none of
>>> >> that scientific stability views. That doesn't mean I don't get their
>>> >> point,
>>> >> I really really do, but still. It's in the job description. Software
>>> is a
>>> >> big part of science just like the papers. (What Matti said)
>>> >> 2- Even a two-year old code is not safe to let it collect dust and
>>> >> constantly requires attention and becomes a liability rather than a
>>> tool
>>> >> (what Bennet said).
>>> >> 3- Matlab breaks things all the time with 0 user consideration. None.
>>> But
>>> >> admittedly they break in style. We shouldn't be like them (not even
>>> >> close)
>>> >> but the point is when it is a commercial product, we don't hear the
>>> >> uproar
>>> >> we receive. People silently fix things.
>>> >> 4- Just because we update the python version, a lot of packages stop
>>> >> working. This is seriously disheartening. Happens to me all the time
>>> >> (protobuf, influxdb etc). And really annoying if one package has not
>>> >> released the new version yet.
>>> >> 5- Python is releasing too quick. I know Python is not Fortran
>>> >> (thankfully) but this is the other end of the spectrum. With every
>>> >> version
>>> >> one or two of us spent at least 2 weeks of intensive "What did they
>>> >> change
>>> >> on Windows again?" bug hunting. Hence our platform is not reliable and
>>> >> now
>>> >> they want  12 months.  (What Ralf said)
>>> >> 6- There are always new users, downloading Python for the first time
>>> and
>>> >> it is expected that SciPy stack should work off-the-shelf. Hence we
>>> don't
>>> >> have the luxury to wait and see (see 4th item).
>>> >> 7- If there are limited resources for software support, then why
>>> people
>>> >> take the risk and update their stuff is something that has been
>>> discussed
>>> >> for decades now. And no one seems to converge to a point. (What Matti
>>> >> said)
>>> >> 8-  what Evgeni suggested
>>> >>
>>> >> I'm not sure what to do about this but I am also more worried about
>>> the
>>> >> Python version than the NumPy version, my limited anectodal evidence
>>> >> around
>>> >> me suggests that people update NumPy + SciPy together mainly when they
>>> >> use
>>> >> pip with -U (--upgrade) on some package that has SciPy as a
>>> dependency.
>>> >> So
>>> >> I feel that it is safe to bump.
>>> >>
>>> >>
>>> > Just for the NumPy perspective, there is nothing in the forthcoming
>>> NumPy
>>> > 1.20 that doesn't work with Python 3.6, it is just a question of what
>>> > wheels to provide. OTOH, as Python advances I don't want to worry about
>>> > someone using newer features, whatever they are.  I go back and forth,
>>> but
>>> > feel that 48 months is about the right support window and that argues
>>> for
>>> > dropping Python 3.6. With the faster pace of Python development we will
>>> > probably want to support the last four versions going forward. Note
>>> that
>>> > SciPy doesn't need to support all the NumPy versions that support a
>>> > particular version of Python, just the latest one. The main concern
>>> doesn't
>>> > seem to be compatibility as much as availability.
>>> >
>>> > <snip>
>>> >
>>> > Chuck
>>> >
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20201114/c4c517b7/attachment.html>