[Numpy-discussion] Fixing numpy 1.4.0 ABI breakage, and a plea for self-contained, small commits

[David Cournapeau]

Alan G Isaac wrote:
>>> On 1/27/2010 7:57 PM, David Cournapeau wrote:
>>>> Guido explicitly asked not to break compatibility while staying under
>>>> py3k, so we should try to do it once numpy has been ported to py3k (e.g.
>>>> if numpy 1.5 still is not py3k compatible, do a 1.6 before a 2.0 -
>>>> iterate if necessary:)  ).
> 
> 
>> Alan G Isaac wrote:
>>> This sounds very different than
>>> http://www.artima.com/weblogs/viewpost.jsp?thread=227041
> 
> 
> On 1/27/2010 8:28 PM, David Cournapeau wrote:
>> Maybe my English is broken, as I meant exactly the same as in Guido's
>> post: do not break API (C API here) while porting to py3k. Making the
>> NumPy C API robust to changes wo constantly breaking the ABI will
>> require heavy changes to C structures and how they are exposed to 3rd
>> parties. It is impossible to do without breaking the C API.
> 
> 
> 
> My reading is: do not see py3k as
> an opportunity for API breakage.

Yup.

> 
> So if breakage is know to be necessary,
> do it now in a forward looking way,
> so that it will not be necessary
> after moving to py3k.
> 
> Quoting from http://www.artima.com/weblogs/viewpost.jsp?thread=227041 :
> "If you have make API changes, do them before you port to 3.0"

Ah, that's the misunderstanding: I think you focus on before vs after, 
but that's not the most important point. The full quote is

" If you have make API changes, do them before you port to 3.0 -- 
release a version with the new API for Python 2.5, or 2.6 if you must. 
(Or do it later, after you've released a port to 3.0 without adding new 
features.)"

What matters is not to do it at the same time, so that porting 3rd party 
code with 2to3 is possible (that's the bolded text). Since the py3k port 
is already underway, it seems natural to me to first release a py3k 
compatible release, and then a new numpy with incompatible API.

OTOH, one could make the argument that releasing the API would avoid 
having to port numpy "twice" (first to py3k with say numpy 1.5.0, then 
to the new API for numpy 2.0). But I am not sure it is a big change in 
practice ?


David