On 11 Mar 2014 14:25, "Paul Brossier" <p...@piem.org> wrote: > > On 11/03/2014 10:49, Nathaniel Smith wrote: > > On 11 Mar 2014 13:28, "Paul Brossier" <p...@piem.org > > <mailto:p...@piem.org>> wrote: > >> If I understand correctly, the current version is the one installed on > >> the user system. So using NPY_API_VERSION would mean "this code should > >> work with any version of numpy". I guess this is what I want (I would > >> even expect this to be the default setting). Did I miss something? > > > > Using NPY_API_VERSION here means "this code will work with any version > > of numpy, *including ones that aren't released yet and might have > > arbitrary API changes*". > > > > This is almost certainly not what you want. > > Thanks for the clarification. > > > The idea of the deprecation support is that it gives you a grace period > > to adapt to upcoming changes before they break your code. Suppose > > PyArray_foo is going to be removed in numpy 1.10. If we just removed it, > > your first warning would be when we release 1.10 and suddenly you have > > angry users who find your software no longer works. So the trick is that > > before we remove it entirely, we release 1.9, in which PyArray_foo is > > available if your NPY_DEPRECATED_API version is set to 1.8 or earlier, > > but not if it's set to 1.9. Your released versions thus continue to > > work, your users are happy, and the first person to encounter the > > problem is you, when you try to update your NPY_DEPRECATED_API to 1.9. > > You fix the problem, you make a new release, and then when 1.10 comes > > along everything works. > > > > Moral: set NPY_DEPRECATED_API to match the highest numpy version you've > > tested. > > I guess you meant NPY_NO_DEPRECATED_API?
Yes. I'm just too lazy to check these things on my phone :-). -n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
