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

Warren Weckesser warren.weckesser at gmail.com
Mon Aug 24 17:47:08 EDT 2020


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?  It might be useful to use
dataclasses (https://docs.python.org/3/library/dataclasses.html), and
they are new in Python 3.7.

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
>


More information about the SciPy-Dev mailing list