<p dir="ltr">On Fri, Sep 28, 2012 at 10:23 PM, Gael Varoquaux <<a href="mailto:gael.varoquaux@normalesup.org">gael.varoquaux@normalesup.org</a>> wrote:<br>
> Hi numpy developers,<br>
><br>
> First of all, thanks a lot for the hard work you put in numpy. I know<br>
> very well that maintaining such a core library is a lot of effort and a<br>
> service to the community. But "with great dedication, comes great<br>
> responsibility" :).</p>
<p dir="ltr">There've been several long discussions about this on numpy-discussion over the last few months, actually... a few that I remember off the top of my head:</p>
<p dir="ltr"><a href="http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062496.html">http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062496.html</a><br>
<a href="http://www.mail-archive.com/numpy-discussion@scipy.org/msg37500.html">http://www.mail-archive.com/numpy-discussion@scipy.org/msg37500.html</a><br>
<a href="http://mail.scipy.org/pipermail/numpy-discussion/2012-May/thread.html#62298">http://mail.scipy.org/pipermail/numpy-discussion/2012-May/thread.html#62298</a></p>
<p dir="ltr">> I find that Numpy is a bit of a wild horse, a moving target. I have just<br>
> fixed a fairly nasty bug in scikit-learn [1] that was introduced by<br>
> change of semantics in ordering when doing copies with numpy. I have been<br>
> running working and developing the scikit-learn while tracking numpy's<br>
> development tree and, as far as I can tell, I never saw warnings raised<br>
> in our code that something was going to change, or had changed.</p>
<p dir="ltr">It looks like this is a bug caused by the 1.7 pre-release versions? Have you reported it? (I swear I saw some code go by recently that involved guessing array orders to match the input, but I can't recall where.) </p>

<p dir="ltr">> In other settings, changes in array inheritance and 'base' propagation<br>
> have made impossible some of our memmap-related usecase that used to work<br>
> under previous numpy [2]. Other's have been hitting difficulties related<br>
> to these changes in behavior [3]. Not to mention the new casting rules<br>
> (default: 'same_kind') that break a lot of code, or the ABI change that,<br>
> while not done an purpose, ended up causing us a lot of pain.</p>
<p dir="ltr">The same_kind rule change has been reverted for 1.7 for exactly this reason, and several dozen changes have gone in in the last month or two trying to clear up all the little regressions we've found so far in 1.7pre. And we've been trying to be more rigorous about following a formal deprecation schedule in general.</p>

<p dir="ltr"><a href="https://github.com/numpy/numpy/pull/440">https://github.com/numpy/numpy/pull/440</a><br>
<a href="https://github.com/numpy/numpy/pull/451">https://github.com/numpy/numpy/pull/451</a><br>
<a href="https://github.com/numpy/numpy/pull/280">https://github.com/numpy/numpy/pull/280</a><br>
<a href="https://github.com/numpy/numpy/pull/350">https://github.com/numpy/numpy/pull/350</a></p>
<p dir="ltr">I have mixed feelings about the .base change. If it were possible to do a deprecation period I'd definitely be in favor, but I don't see how, unless we were to remove accessing it from python altogether, and that's pretty unlikely. The problem is it's an attractive nuisance; the *only* reliable thing you've *ever* been able to do with it is pin an object in memory when constructing an array directly, but people keep expecting more, so all the breakages have been in code that was IMHO already on thin ice. And from my point of view it wouldn't be the *most* terrible thing if the result here is that you're forced to make memmap pickling work in numpy directly for everybody ;-). But I go back and forth in my own mind, because of the things you say. Other ideas very welcome. (Maybe we should rename the python attribute to ._base - with appropriate deprecation period of course - just to encourage people to stop doing unwise things with it, and *then* make the change that's tripping you up now?)</p>

<p dir="ltr">> My point here is that having code that works and gives correct results<br>
> with new releases of numpy is more challenging that it should be. I<br>
> cannot claim that I disagree with the changes that I mention above. They<br>
> were all implemented for a good reason and can all be considered as<br>
> overall improvements to numpy. However the situation is that given a<br>
> complex codebase relying on numpy that works at a time t, the chances<br>
> that it works flawlessly at time t + 1y are thin. I am not too proud that<br>
> we managed to release scikit-learn 0.12 with a very ugly bug under numpy<br>
> 1.7. That happened although we have 90% of test coverage, buildbots under<br>
> different numpy versions, and a lot of people, including me, using our<br>
> development tree on a day to day basis with bleeding edge numpy. Most<br>
> code in research settings or RD industry does not benefit from such<br>
> software engineering and I believe is much more likely to suffer from<br>
> changes in numpy.<br>
><br>
> I think that this is a cultural issue: priority is not given to stability<br>
> and backward compatibility. I think that this culture is very much<br>
> ingrained in the Python world, that likes iteratively cleaning its<br>
> software design. For instance, I have the feeling that in the<br>
> scikit-learn, we probably fall in the same trap. That said, such a<br>
> behavior cannot fare well for a base scientific environment. People tell<br>
> me that if they take old matlab code, the odds that it will still works<br>
> is much higher than with Python code. As a geek, I tend to reply that we<br>
> get a lot out of this mobility, because we accumulate less cruft.<br>
> However, in research settings, for reproducibility reasons, ones need to<br>
> be able to pick up an old codebase and trust its results without knowing<br>
> its intricacies.<br>
><br>
> >From a practical standpoint, I believe that people implementing large<br>
> changes to the numpy codebase, or any other core scipy package, should<br>
> think really hard about their impact. I do realise that the changes are<br>
> discussed on the mailing lists, but there is a lot of activity to follow<br>
> and I don't believe that it is possible for many of us to monitor the<br>
> discussions. Also, putting more emphasis on backward compatibility is<br>
> possible. For instance, the 'order' parameter added to np.copy could have<br>
> defaulted to the old behavior, 'K', for a year, with a<br>
> DeprecationWarning, same thing for the casting rules.</p>
<p dir="ltr">Maybe it still can, but you have to tell us details :-)</p>
<p dir="ltr">In general numpy development just needs more people keeping track of these things. If you want to keep an open source stack functional sometimes you have to pay a tax of your time to making sure the levels below you will continue to suit your needs.</p>

<p dir="ltr">-n</p>
<p dir="ltr">> Thank you for reading this long email. I don't mean it to be a complaint<br>
> about the past, but more a suggestion on something to keep in mind when<br>
> making changes to core projects.<br>
><br>
> Cheers,<br>
><br>
> Gaël<br>
><br>
> ____<br>
><br>
> [1] <a href="https://github.com/scikit-learn/scikit-learn/commit/7842748cf777412c506a8c0ed28090711d3a3783">https://github.com/scikit-learn/scikit-learn/commit/7842748cf777412c506a8c0ed28090711d3a3783</a><br>
><br>
> [2] <a href="http://mail.scipy.org/pipermail/numpy-discussion/2012-September/063985.html">http://mail.scipy.org/pipermail/numpy-discussion/2012-September/063985.html</a><br>
><br>
> [3] <a href="http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063126.html">http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063126.html</a><br>
><br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</p>