<!DOCTYPE html>
<html>
<head>
<title></title>
<style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
</head>
<body><div>On Fri, Nov 17, 2017, at 13:12, Chris Barker wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div defang_data-gmailquote="yes"><div>On Fri, Nov 17, 2017 at 4:35 AM, Peter Cock <span dir="ltr"><<a href="mailto:p.j.a.cock@googlemail.com">p.j.a.cock@googlemail.com</a>></span> wrote:<br></div>
<blockquote defang_data-gmailquote="yes" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div>Since Konrad Hinsen no longer follows the NumPy discussion list<br></div>
<div> for lack of time, he has not posted here - but he has commented<br></div>
<div> about this on Twitter and written up a good blog post:<br></div>
<div> <br></div>
<div> <a href="http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/">http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/</a><br></div>
</blockquote></div>
</div>
</div>
</blockquote><div><br></div>
<div>I don't agree with the general gist of Konrad's post. There are multiple viewpoints on the issue, of course, such as that of developers that are already invested in NumPy or SciPy's APIs, those that will rely on it in the future, and those that are still undecided about whether to use these tools.<br></div>
<div><br></div>
<div>For those heavily invested such as Konrad, API changes and a language upgrade may seem like a particularly bad situation. Heck, none of us enjoyed having to port all of our code to Python 3, but in reality the changes required were much fewer than commonly imagined and are documented.<br></div>
<div><br></div>
<div>But in the same way you cause some pain by changing APIs, *not* changing APIs carries a penalty too, more for the other groups I mentioned. The ability to change APIs, albeit slowly, allows cleaner and more intuitive future code, fewer surprises, and makes the environment much more enjoyable to use.<br></div>
<div><br></div>
<div>We can do a better job of advertising NumPy's deprecation policy. A quick Google search for "x deprecation policy" didn't manage to find it, but did pick up:<br></div>
<div><br></div>
<div><div>- <a href="http://scikit-learn.org/stable/developers/contributing.html#deprecation">http://scikit-learn.org/stable/developers/contributing.html#deprecation</a><br></div>
<div></div>
<div>- <a href="http://scikit-image.org/docs/dev/contribute.html#deprecation-cycle">http://scikit-image.org/docs/dev/contribute.html#deprecation-cycle</a><br></div>
<div>- <a href="https://docs.scipy.org/doc/scipy-1.0.0/reference/dev/deprecations.html">https://docs.scipy.org/doc/scipy-1.0.0/reference/dev/deprecations.html</a><br></div>
</div>
<div><br></div>
<div>All the above packages, as well as NumPy, include a section on API changes in their release notes.<br></div>
<div><br></div>
<div>We may benefit from standardizing deprecation conventions across the community, so that there is a very clear expectation on how often to run your code to be able to see all relevant warnings and fix them.<br></div>
<div><br></div>
<div>Best regards<br></div>
<div>Stéfan<br></div>
<div><br></div>
</body>
</html>