[Numpy-discussion] Created NumPy 1.7.x branch

David Cournapeau cournape at gmail.com
Tue Jun 26 05:58:59 EDT 2012

On Tue, Jun 26, 2012 at 10:27 AM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> On 06/26/2012 05:35 AM, David Cournapeau wrote:
>> On Tue, Jun 26, 2012 at 4:10 AM, Ondřej Čertík<ondrej.certik at gmail.com>  wrote:
>>> My understanding is that Travis is simply trying to stress "We have to
>>> think about the implications of our changes on existing users." and
>>> also that little changes (with the best intentions!) that however mean
>>> either a breakage or confusion for users (due to historical reasons)
>>> should be avoided if possible. And I very strongly feel the same way.
>>> And I think that most people on this list do as well.
>> I think Travis is more concerned about API than ABI changes (in that
>> example for 1.4, the ABI breakage was caused by a change that was
>> pushed by Travis IIRC).
>> The relative importance of API vs ABI is a tough one: I think ABI
>> breakage is as bad as API breakage (but matter in different
>> circumstances), but it is hard to improve the situation around our ABI
>> without changing the API (especially everything around macros and
>> publicly accessible structures). Changing this is politically
> But I think it is *possible* to get to a situation where ABI isn't
> broken without changing API. I have posted such a proposal.
> If one uses the kind of C-level duck typing I describe in the link
> below, one would do
> typedef PyObject PyArrayObject;
> typedef struct {
>    ...
> } NumPyArray; /* used to be PyArrayObject */

Maybe we're just in violent agreement, but whatever ends up being used
would require to change the *current* C API, right ? If one wants to
allow for changes in our structures more freely, we have to hide them
from the headers, which means breaking the code that depends on the
structure binary layout. Any code that access those directly will need
to be changed.

There is the particular issue of iterator, which seem quite difficult
to make "ABI-safe" without losing significant performance.



More information about the NumPy-Discussion mailing list