Deprecate unused but exposed C-API functions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecate unused but exposed C-API functions

Sebastian Berg
Hi all,

I would like to deprecate three C-API functions (more may come later)
in https://github.com/numpy/numpy/pull/15427

The functions are:
  * PyArray_GetArrayParamsFromObject
  * PyUfunc_GenericCall
  * PyUFunc_SetUsesArraysAsData

I could not find downstream usage for any of these and they seem useful
only on first glance to me.

The first one is too complex (regarding scalars), simply converting to
an array first should be just as well.
The second one is almost identical to `PyObject_Call`. And the third
one is not even documented and while the idea is sound, I am not sure
that there are any cases where it is useful [0]

My idea is to add the deprecation warning now, and if nobody notices it
remove them as soon as 1.19 is released.

- Sebastian


[0] It seems useful for user datatypes/loop, but using it for those
does not seem possible (or at least straight forward), since they are
usually stored in a way not accessible through this function.

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate unused but exposed C-API functions

Charles R Harris


On Fri, Jan 24, 2020 at 11:29 AM Sebastian Berg <[hidden email]> wrote:
Hi all,

I would like to deprecate three C-API functions (more may come later)
in https://github.com/numpy/numpy/pull/15427

The functions are:
  * PyArray_GetArrayParamsFromObject
  * PyUfunc_GenericCall
  * PyUFunc_SetUsesArraysAsData

I could not find downstream usage for any of these and they seem useful
only on first glance to me.

The first one is too complex (regarding scalars), simply converting to
an array first should be just as well.
The second one is almost identical to `PyObject_Call`. And the third
one is not even documented and while the idea is sound, I am not sure
that there are any cases where it is useful [0]

My idea is to add the deprecation warning now, and if nobody notices it
remove them as soon as 1.19 is released.


I don't think C-API functions should be removed. Deprecation is fine, but removal changes the customary order of the functions. If they cost nothing to maintain, just leave them alone with a note/documentation that there are preferable alternatives.

Chuck

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate unused but exposed C-API functions

Sebastian Berg
On Fri, 2020-01-24 at 17:56 -0700, Charles R Harris wrote:
>
>
> On Fri, Jan 24, 2020 at 11:29 AM Sebastian Berg <
> [hidden email]> wrote:
> > Hi all,
> >
<snip>

> >
> > My idea is to add the deprecation warning now, and if nobody
> > notices it
> > remove them as soon as 1.19 is released.
> >
>
> I don't think C-API functions should be removed. Deprecation is fine,
> but removal changes the customary order of the functions. If they
> cost nothing to maintain, just leave them alone with a
> note/documentation that there are preferable alternatives.
>
To be clear: removal in this sense for me would mean that they exist as
a stub which always raises an error.
In principle they could be set to NULL as well, but I think the always-
error solution is just as good probably.

- Sebastian


> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment