<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 18, 2020 at 3:58 AM Tyler Reddy <<a href="mailto:tyler.je.reddy@gmail.com" target="_blank">tyler.je.reddy@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"><br><div><div>I can pretty much guarantee that we will take on a non-zero maintenance burden if we support an additional Python version. Devs spend a fair bit of time just "keeping CI green" so that new contributions/fixes can flow in without confusion/delays, and that is compounded by the backport CI and separate wheels repo CI.</div></div></div></blockquote><div><br></div><div>Yep, this really is the main argument.</div><div> <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><div><br></div><div>If you convince Ralf et al. that we should go against the NEP I don't really mind, but it is going to cost us time that could be spent on other things.</div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Aug 2020 at 06:59, Bennet Fauber <<a href="mailto:bennet@umich.edu" target="_blank">bennet@umich.edu</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">Boy, yes, Ilhan, I agree.  Too many different roles in my head!<br>
<br>
Just to be clear, I also am not concerned about deprecating older<br>
NumPy, only the base Python version, and specifically 3.6.  It looks<br>
like the latest fully released NumPy supports Python 3.6.  In my Linux<br>
world, we still have a preponderance of RedHat/CentOS 7 installed, and<br>
it does not easily provide Python 3.7:  python36 is available from<br>
EPEL.  Our most prevalent Ubuntu is 16.04.  We will probably jump to<br>
20.04 next calendar year. <br></blockquote></div></blockquote><div><br></div><div>`pip install scipy --user`, or whatever you do on an old CentOS machine/cluster, is still going to work. As is `apt-get install scipy`. And it will get you the latest supported SciPy for that Python version, which is pretty good. All you're missing out on is a few new features and bug fixes in 1.6.0. If you discover you need those, it's time to learn Conda so it's trivial to install a newer Python version.<br></div><div> <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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I had not realized that Python itself was going to a 12-month release<br>
cycle.  That seems to me destructive and predicated on the notion that<br>
software is disposable.<br></blockquote></div></blockquote><div><br></div><div>I have to admit I'm not a fan, but that's because new Python versions typically bring us new burdens and few or no new features we need. Having bug fixes propagate a bit faster is the upside.<br></div><div> <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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think there is a very good reason why many Linux distributions have<br>
separate distributions for longer term stability and more up-to-date<br>
features.  Red Hat and Fedora, Ubuntu and LTS, Debian Stable and<br>
Unstable.  Is that viable with SciPy, NumPy, where only the bug fixes<br>
get backported, which might reduce the cost of longer maintenance<br>
(except for the wheels, as noted)?<br>
<br>
Thanks for the discussion on this, no matter where it ends up.<br>
<br>
><br>
> On Mon, Aug 17, 2020 at 12:19 AM Evgeni Burovski <<a href="mailto:evgeny.burovskiy@gmail.com" target="_blank">evgeny.burovskiy@gmail.com</a>> wrote:<br>
>><br>
>> No objections for bumping the minimum NumPy version.<br>
>> For bumping the python version.. not quite an objection, more of a suggestion to consider holding it back.<br>
>> I guess there are three kinds of stakeholders here:<br>
>> - for end users, upgrading the python version is a fairly major hassle. Three versions of python now means three years back if they switch to a 12-months cadence. Three years of support is definitely on a low side of things. (with my PI hat on, I can certainly relate to what Bennet was saying, even if our lab has it way easier than others).<br></blockquote></div></blockquote><div><br></div><div>Python 3.6 was released in Dec 2016, and we're talking about our Dec 2020 release - so 4 years. When it's actually down to 3 years we can review again, but that's not today's decision.<br></div><div> <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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> - for the scipy devs, what exactly drives us to drop it? For 3.5 it was of course the matmul operator, for 3.6 it's f-strings, what's there in 3.7 which makes it not fun to stay on 3.6?<br></blockquote></div></blockquote><div><br></div><div>f-strings are/were not very interesting imho. If you spend all day doing string processing yes, but for numerical code it really doesn't matter all that much. We had two ways of doing string formatting, now we have three.<br></div><div><br></div><div>As Tyler said, it's to reduce the cost of keeping it working, and CI happy. We can spend that time writing or reviewing new features and other improvements instead.</div><div><br></div><div>Cheers,</div><div>Ralf</div><div><br></div><div> <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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> - for the RM and other packagers: how much of a hassle is it to keep an older version? I realize it's more wheels to build for the scipy RM, but that's fairly automated now? <br></blockquote></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>><br>
>><br>
>> Cheers,<br>
>> Evgeni<br>
>><br>
>><br>
>> On Sun, Aug 16, 2020 at 6:22 PM Matti Picus <<a href="mailto:matti.picus@gmail.com" target="_blank">matti.picus@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On 8/16/20 4:23 PM, Bennet Fauber wrote:<br>
>> > > This post is by way of trying to articulate some concerns from the end<br>
>> > > user side of things.<br>
>> > ><br>
>> > > It looks like NumPy 19.1 supports Python 3.6.<br>
>> > ><br>
>> > >> This release supports Python 3.6-3.8. Cython >= 0.29.21 needs to be used when building<br>
>> > >> with Python 3.9 for testing purposes.<br>
>> > > <a href="https://numpy.org/devdocs/release/1.19.1-notes.html" rel="noreferrer" target="_blank">https://numpy.org/devdocs/release/1.19.1-notes.html</a><br>
>> > ><br>
>> > > The section of the release notes for NumPy 1.20.0 does not contain the<br>
>> > > section at the top saying which versions of Python are supported.<br>
>> > > (<a href="https://numpy.org/devdocs/release/1.20.0-notes.html" rel="noreferrer" target="_blank">https://numpy.org/devdocs/release/1.20.0-notes.html</a>)<br>
>> > ><br>
>> > > For Python itself,  I find on their releases, the 3.6.12 schedule was<br>
>> > ><br>
>> > >      3.6.12 final: 2020-08-14 (expected)<br>
>> > > <a href="https://www.python.org/dev/peps/pep-0494/#id9" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0494/#id9</a><br>
>> > ><br>
>> > > but does not seem to have made it, and Python 3.6.11 was released June<br>
>> > > 27, 2020.  The Python plans for 3.6.13 and beyond are Security fixes<br>
>> > > only, as needed, until 2021-12.  That seems, from my user perspective,<br>
>> > > a better date for deprecation and not too far from the just proposed<br>
>> > > one.<br>
>> > ><br>
>> > > Acknowledging the additional burden of 'supporting' older versions of<br>
>> > > Python, still it would seem that matching NumPy is not a bad thing.<br>
>> > ><br>
>> > >  From a strictly consumer perspective, where much of the work is<br>
>> > > getting all of the non-NumPy and non-SciPy functionality to work and<br>
>> > > be stable, upgrading Python can be very disruptive.  Time spent<br>
>> > > getting the 'glue' around analytics to work is time we cannot spend on<br>
>> > > science.  There are large projects that do keep up, but they tend also<br>
>> > > to be funded well.  The many small labs on my campus do not have<br>
>> > > funding for software development, are unlikely to ever get any, so any<br>
>> > > work required to fix software because of updates comes from their<br>
>> > > budget for science and from their scientists who are not as proficient<br>
>> > > and therefore not as efficient at adapting to a newer version of<br>
>> > > Python and all the reinstallation of libraries that attends it.<br>
>> > ><br>
>> ><br>
>> > Is there a forum where we could explore the larger question around best<br>
>> > practices in helping projects and teams keep their software up-to-date<br>
>> > through rolling updates, test suites, and documentation? A few things<br>
>> > come to mind:<br>
>> ><br>
>> > - developing a culture of version control and tests when creating<br>
>> > software, even if it is grad students racing towards their degrees<br>
>> ><br>
>> > - freezing environments in images, which is a whole discipline unto<br>
>> > itself, and needed for reproducible science<br>
>> ><br>
>> > - offloading the task of maintaining computing environments using things<br>
>> > like Jupyter Hub or other web-based services<br>
>> ><br>
>> ><br>
>> > FWIW, python is changing their release cadence from once every 18 months<br>
>> > to once every 12 months[1] so it is likely this problem will get harder.<br>
>> ><br>
>> > Matti<br>
>> ><br>
>> > [1] <a href="https://www.python.org/dev/peps/pep-0602/#annual-release-cadence" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0602/#annual-release-cadence</a><br>
>> > _______________________________________________<br>
>> > SciPy-Dev mailing list<br>
>> > <a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
>> > <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/scipy-dev</a><br>
>> _______________________________________________<br>
>> SciPy-Dev mailing list<br>
>> <a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
>> <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/scipy-dev</a><br>
><br>
> _______________________________________________<br>
> SciPy-Dev mailing list<br>
> <a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/scipy-dev</a><br>
_______________________________________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/scipy-dev</a><br>
</blockquote></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/scipy-dev</a><br>
</blockquote></div></div>