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

Sat Nov 14 18:06:25 EST 2020

On Sat, Nov 14, 2020 at 10:47 PM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> Hi Ralf,
>
> I opened one yesterday: https://github.com/scipy/scipy/pull/13081
>
> Feel free to replace it though. It was based almost purely on the commit
> where you did the same thing for 3.5 last time.
>

Sorry, I've got my notifications disabled. Ignore the noise, your PR looks
good!

Cheers,
Ralf

> Tyler
>
> On Sat, 14 Nov 2020 at 15:39, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>>
>>
>> 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
>>>
>> _______________________________________________
>> 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/9f5ffeb9/attachment.html>