[Numpy-discussion] draft NEP for breaking ufunc ABI in a controlled way

[Nathaniel Smith]

Hi Antoine,

On Mon, Sep 21, 2015 at 2:44 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hi Nathaniel,
>
> On Sun, 20 Sep 2015 21:13:30 -0700
> Nathaniel Smith <njs at pobox.com> wrote:
>> Given this, I propose that for 1.11 we:
>> 1) go ahead and hide/disable the problematic parts of the ABI/API,
>> 2) coordinate with the known affected projects to minimize disruption
>> to their users (which is made easier since they are all projects that
>> are almost exclusively distributed via conda, which enforces strict
>> NumPy ABI versioning),
>> 3) publicize these changes widely so as to give any private code that
>> might be affected a chance to speak up or adapt, and
>> 4) leave the "ABI version tag" as it is, so as not to force rebuilds
>> of the vast majority of projects that will be unaffected by these
>> changes.
>
> Thanks for a detailed and clear explanation of the proposed changes.
> As far as Numba is concerned, making changes is ok for us provided
> Numpy provides APIs to do what we want.

Good to hear, thanks!

Any interest in designing those new APIs that will do what you want?
:-) A no-brainer is that PyUFuncObject should just take responsibility
for managing the memory of its own internal arrays instead of assuming
that they'll always be statically allocated and forcing elaborate
workarounds when they're not, but there is a lot of complicated stuff
going on in numba/npyufunc/_internal.c... I am even wondering whether
we should go ahead and reify a first-class "ufunc loop" object, so it
can have its own refcounting.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org