<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 16, 2020 at 5:17 PM Ilhan Polat <<a href="mailto:ilhanpolat@gmail.com">ilhanpolat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I have too many personas in my head arguing about this. And many of them are in conflict.<br></div><div><br></div><div>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)<br></div><div>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).</div><div>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. <br></div><div>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.<br></div><div>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)<br></div><div>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). <br></div><div>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)<br></div><div></div><div>8-  what Evgeni suggested<br></div><div></div><div><br></div><div>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.<br></div><div><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div><snip></div><div><br></div><div>Chuck</div></div></div>