[Numpy-discussion] Created NumPy 1.7.x branch

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Tue Jun 26 05:27:24 EDT 2012

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 */

Thus, a ABI-hiding PyArray_SHAPE function could take either a 
PyArrayObject* or a PyObject*, since they would be the same.


(The technical parts are a bit out of date; me and Robert Bradshaw are 
in the 4th iteration of that concept for use within Cython, we are now 
hovering around perfect-hashing lookup tables that have 1ns 
branch-miss-free lookups and uses ~20us for construction/initialization).


More information about the NumPy-Discussion mailing list