Hi All, This is apropos ticket #805 <http://scipy.org/scipy/numpy/ticket/805>. The reporter wants to change the signature of the functions PyArray_FromDims and PyArray_FromDimsAndDataAndDesc, which we really can't do at this point because they are part of the Numpy API. The problem can be seen in the current signatures: PyArray_FromDims(int nd, int *d, int type) PyArray_FromDimsAndDataAndDescr(int nd, int *d, PyArray_Descr *descr, char *data) where d points to the desired dimensions. On 64 bit architectures the int type can be too small to hold the dimensions. Now these functions are old and retained for compatibility; the user's problem turned up in num_utils, which is a C++ interface to Numeric. Quite possibly other programs use it also (BOOST?). So the question is, how do we go about dealing with this. Do we remove them at some point, breaking compatibility and the current API? If so, when do we do this? Should we issue a deprecation warning? If so, how do we do it from C? Should it show up at run time or compile time? Chuck
On Sun, Jul 13, 2008 at 00:44, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
This is apropos ticket #805. The reporter wants to change the signature of the functions PyArray_FromDims and PyArray_FromDimsAndDataAndDesc, which we really can't do at this point because they are part of the Numpy API. The problem can be seen in the current signatures:
PyArray_FromDims(int nd, int *d, int type) PyArray_FromDimsAndDataAndDescr(int nd, int *d, PyArray_Descr *descr, char *data)
where d points to the desired dimensions. On 64 bit architectures the int type can be too small to hold the dimensions. Now these functions are old and retained for compatibility; the user's problem turned up in num_utils, which is a C++ interface to Numeric. Quite possibly other programs use it also (BOOST?).
So the question is, how do we go about dealing with this. Do we remove them at some point, breaking compatibility and the current API? If so, when do we do this?
The original vision was to remove numpy.oldnumeric and (I think) numpy/oldnumeric.h at what was envisioned as "1.1" long ago when we were still at 0.9 or so. That vision has been overcome by events, I think. Given the evidence of people's adoption, I don't quite think it's time to remove the compatibility APIs wholesale, yet. However, for problematic APIs like this one, I think we can issue a DeprecationWarning (see below) in 1.2, and schedule them for removal in 1.3. In 1.3 until the whole compatibility API is removed, we can have these APIs just contain an #error such that they stop the build at compile time.
Should we issue a deprecation warning? If so, how do we do it from C? Should it show up at run time or compile time?
Compile-time warnings will be ignored if they aren't errors that stop the build. Run-time DeprecationWarnings are feasible: http://docs.python.org/dev/c-api/exceptions.html#PyErr_WarnEx -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sun, Jul 13, 2008 at 12:02 AM, Robert Kern <robert.kern@gmail.com> wrote:
Hi All,
This is apropos ticket #805. The reporter wants to change the signature of the functions PyArray_FromDims and PyArray_FromDimsAndDataAndDesc, which we really can't do at this point because they are part of the Numpy API. The problem can be seen in the current signatures:
PyArray_FromDims(int nd, int *d, int type) PyArray_FromDimsAndDataAndDescr(int nd, int *d, PyArray_Descr *descr, char *data)
where d points to the desired dimensions. On 64 bit architectures the int type can be too small to hold the dimensions. Now these functions are old and retained for compatibility; the user's problem turned up in num_utils, which is a C++ interface to Numeric. Quite possibly other programs use it also (BOOST?).
So the question is, how do we go about dealing with this. Do we remove
On Sun, Jul 13, 2008 at 00:44, Charles R Harris <charlesr.harris@gmail.com> wrote: them
at some point, breaking compatibility and the current API? If so, when do we do this?
The original vision was to remove numpy.oldnumeric and (I think) numpy/oldnumeric.h at what was envisioned as "1.1" long ago when we were still at 0.9 or so. That vision has been overcome by events, I think.
Given the evidence of people's adoption, I don't quite think it's time to remove the compatibility APIs wholesale, yet. However, for problematic APIs like this one, I think we can issue a DeprecationWarning (see below) in 1.2, and schedule them for removal in 1.3. In 1.3 until the whole compatibility API is removed, we can have these APIs just contain an #error such that they stop the build at compile time.
Should we issue a deprecation warning? If so, how do we do it from C? Should it show up at run time or compile time?
Compile-time warnings will be ignored if they aren't errors that stop the build. Run-time DeprecationWarnings are feasible:
http://docs.python.org/dev/c-api/exceptions.html#PyErr_WarnEx
OK, will do. The same user wants to fix up fftpack_lite. This should actually be pretty easy, just replace all ints by longs in fftpack and fftpack_lite. Or maybe we should use one of the python.h types. As far as I know, these functions are only exposed through the python interface. Chuck
-- Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Jul 13, 2008 at 01:49, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jul 13, 2008 at 12:02 AM, Robert Kern <robert.kern@gmail.com> wrote:
Compile-time warnings will be ignored if they aren't errors that stop the build. Run-time DeprecationWarnings are feasible:
http://docs.python.org/dev/c-api/exceptions.html#PyErr_WarnEx
OK, will do. The same user wants to fix up fftpack_lite. This should actually be pretty easy, just replace all ints by longs in fftpack and fftpack_lite. Or maybe we should use one of the python.h types. As far as I know, these functions are only exposed through the python interface.
Py_ssize_t and Py_size_t are probably the most appropriate, in this case. long is not always the same size as a pointer address. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sun, Jul 13, 2008 at 12:53 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Jul 13, 2008 at 01:49, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jul 13, 2008 at 12:02 AM, Robert Kern <robert.kern@gmail.com>
wrote:
Compile-time warnings will be ignored if they aren't errors that stop the build. Run-time DeprecationWarnings are feasible:
http://docs.python.org/dev/c-api/exceptions.html#PyErr_WarnEx
OK, will do. The same user wants to fix up fftpack_lite. This should actually be pretty easy, just replace all ints by longs in fftpack and fftpack_lite. Or maybe we should use one of the python.h types. As far as I know, these functions are only exposed through the python interface.
Py_ssize_t and Py_size_t are probably the most appropriate, in this case. long is not always the same size as a pointer address.
I'll go with Py_ssize_t then, I'd have to vet the code before using an unsigned type. Hmm, I wonder if any of the npy types defined in terms of the corresponding python types? If not, npy_intp might be the best choice since it will be needed to create arrays. Chuck
On Sun, Jul 13, 2008 at 02:17, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jul 13, 2008 at 12:53 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Jul 13, 2008 at 01:49, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jul 13, 2008 at 12:02 AM, Robert Kern <robert.kern@gmail.com> wrote:
Compile-time warnings will be ignored if they aren't errors that stop the build. Run-time DeprecationWarnings are feasible:
http://docs.python.org/dev/c-api/exceptions.html#PyErr_WarnEx
OK, will do. The same user wants to fix up fftpack_lite. This should actually be pretty easy, just replace all ints by longs in fftpack and fftpack_lite. Or maybe we should use one of the python.h types. As far as I know, these functions are only exposed through the python interface.
Py_ssize_t and Py_size_t are probably the most appropriate, in this case. long is not always the same size as a pointer address.
I'll go with Py_ssize_t then, I'd have to vet the code before using an unsigned type. Hmm, I wonder if any of the npy types defined in terms of the corresponding python types? If not, npy_intp might be the best choice since it will be needed to create arrays.
Yes, npy_intp would probably be better from the reader's point of view. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (2)
-
Charles R Harris -
Robert Kern