c api deprecations with NPY_NO_DEPRECATED_API
hi all, I'm trying to understand how to use the deprecation mechanism. 1. When not defining NPY_NO_DEPRECATED_API, I get warnings (as expected): #warning "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" 2. When defining NPY_NO_DEPRECATED_API, as mentioned in the above warning and in the documentation, I get this error: #error Should never include npy_deprecated_api directly. 3. If instead I include <numpy/npy_no_deprecated_api.h>, I get no warning at all, and the extension builds as expected. Now, why does the second error occur, whereas I do not include npy_deprecated_api.h, and most important, what is the correct way to use the deprecation mechanism? There seems to be a few issues related to this on github, most of them closed, but reading them did not help me understanding. The extension i'm trying to improve is aubio and can be found at http://aubio.org. A copy of the relevant code is at: https://github.com/piem/aubio/blob/develop/python/ext/aubio-types.h thanks, piem
On Sat, Mar 8, 2014 at 2:54 PM, Paul Brossier <piem@piem.org> wrote:
hi all,
I'm trying to understand how to use the deprecation mechanism.
1. When not defining NPY_NO_DEPRECATED_API, I get warnings (as expected):
#warning "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
2. When defining NPY_NO_DEPRECATED_API, as mentioned in the above warning and in the documentation, I get this error:
#error Should never include npy_deprecated_api directly.
3. If instead I include <numpy/npy_no_deprecated_api.h>, I get no warning at all, and the extension builds as expected.
Now, why does the second error occur, whereas I do not include npy_deprecated_api.h, and most important, what is the correct way to use the deprecation mechanism?
There seems to be a few issues related to this on github, most of them closed, but reading them did not help me understanding.
The extension i'm trying to improve is aubio and can be found at http://aubio.org. A copy of the relevant code is at:
https://github.com/piem/aubio/blob/develop/python/ext/aubio-types.h
You should include the same files whether or not NPY_NO_DEPRECATED_API is defined. Usually numpy/arrayobject.h is the only needed include file. For instance, fftpack_litemodule.c has at the top #define NPY_NO_DEPRECATED_API NPY_API_VERSION #include "fftpack.h" #include "Python.h" #include "numpy/arrayobject.h" Where in this case NPY_API_VERSION is the current version, NPY_1_7_API_VERSION would be the numpy1.7.x API, etc. You use the version you intend to support and things deprecated after that version will still be available to you. Chuck
On 08/03/2014 19:25, Charles R Harris wrote:
Thanks for your quick reply Charles.
On Sat, Mar 8, 2014 at 2:54 PM, Paul Brossier <piem@piem.org <mailto:piem@piem.org>> wrote:
2. When defining NPY_NO_DEPRECATED_API, as mentioned in the above warning and in the documentation, I get this error:
#error Should never include npy_deprecated_api directly.
ok, this error was triggered by some older version of numpy, 1.8.0.dev-4600b2f-20130131. updating to 1.8.0 fixed it. sorry for the noise!
The extension i'm trying to improve is aubio and can be found at http://aubio.org. A copy of the relevant code is at:
https://github.com/piem/aubio/blob/develop/python/ext/aubio-types.h
You should include the same files whether or not NPY_NO_DEPRECATED_API is defined. Usually numpy/arrayobject.h is the only needed include file. For instance, fftpack_litemodule.c has at the top
#define NPY_NO_DEPRECATED_API NPY_API_VERSION
#include "fftpack.h" #include "Python.h" #include "numpy/arrayobject.h"
Yes, that's pretty much what I do in aubio.
Where in this case NPY_API_VERSION is the current version, NPY_1_7_API_VERSION would be the numpy1.7.x API, etc. You use the version you intend to support and things deprecated after that version will still be available to you.
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? Thanks, Paul
On 11 Mar 2014 13:28, "Paul Brossier" <piem@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. 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. -n
On 11/03/2014 10:49, Nathaniel Smith wrote:
On 11 Mar 2014 13:28, "Paul Brossier" <piem@piem.org <mailto:piem@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? Paul
On 11 Mar 2014 14:25, "Paul Brossier" <piem@piem.org> wrote:
On 11/03/2014 10:49, Nathaniel Smith wrote:
On 11 Mar 2014 13:28, "Paul Brossier" <piem@piem.org <mailto:piem@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
participants (3)
-
Charles R Harris -
Nathaniel Smith -
Paul Brossier