On 06/26/2012 05:35 AM, David Cournapeau wrote: > On Tue, Jun 26, 2012 at 4:10 AM, Ondřej Čertík<ondrej.cer...@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. http://thread.gmane.org/gmane.comp.python.numeric.general/49997 (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). Dag _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion