[Numpy-discussion] NumPy SVN broken

[David Cournapeau]

On Thu, Oct 8, 2009 at 8:55 PM, Travis Oliphant <oliphant at enthought.com> wrote:
>
> On Oct 7, 2009, at 9:51 PM, David Cournapeau wrote:
>
> On Thu, Oct 8, 2009 at 11:39 AM, Travis Oliphant <oliphant at enthought.com>
> wrote:
>
> I apologize for the mis communication that has occurred here.
>
> No problem
>
>   I did not
>
> understand that there was a desire to keep ABI compatibility with NumPy 1.3
>
> when NumPy 1.4 was released.    The datetime merge was made under that
>
> presumption.
>
> I had assumed that people would be fine with recompilation of extension
>
> modules that depend on the NumPy C-API.    There are several things that
>
> needed to be done to merge in new fundamental data-types.
>
> Why don't we call the next release NumPy 2.0 if that helps things?
>
>  Personally, I'd prefer that over hacks to keep ABI compatibility.
>
> Keeping ABI compatibility by itself is not an hack - the current
> workaround is an hack, but that's only because the current way of
> doing things in code generator is a bit ugly, and I did not want to
> spend too much time on it. It is purely an implementation issue, the
> fundamental idea is straightforward.
>
> If you want a cleaner solution, I can work on it. I think the hour or
> so that it would take is worth it compared to breaking many people's
> code.
>
> If that's all it would take, then definitely go for it.    I'm not sure
> "breaking people's code" is the right image, though.   It's more like
> "forcing people to upgrade" to take advantage of new features.

We got several people complaining about segfaults and the like -
granted, those could have been avoided by updating the ABI
accordingly.

> The problem I have with spending time on it though is that there is still
> more implementation work to finish on the datetime functionality to complete
> the NEP implementation.      Naturally, I'd like to see those improvements
> made first.  But, time-spent is usually a function of how much time it takes
> to "get-in" to the code, so I won't try to distract you if you have a clear
> idea about how to proceed.

I am applying my changes as we speak - it took me much more time than
I wished because I tried hard to make sure the ABI was not changed.
But at least, the current scheme should be much more robust: the
ordering is fixed at one single place, and there are a few checks
which ensure we don't screw things up (by putting 'holes' in the api
array, or by using twice the same index).

cheers,

David