On Wed, Oct 7, 2009 at 8:39 PM, Travis Oliphant <oliph...@enthought.com>wrote:
> > On Oct 7, 2009, at 3:06 AM, David Cournapeau wrote: > > On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris > <charlesr.har...@gmail.com> wrote: > > > > Looks like a clue ;) > > > Ok, I fixed it here: > > http://github.com/cournape/numpy/tree/fix_abi > > But that's an ugly hack. I think we should consider rewriting how we > generate the API: instead of automatically growing the API array of > fptr, we should explicitly mark which function name has which index, > and hardcode it. It would help quite a bit to avoid changing the ABI > unvoluntary. > > > I apologize for the mis communication that has occurred here. 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. It > feels like we are working very hard to track ABI issues that can also be > handled with dependency checking and good package management. > > I was that the code generator shifted the API order because it was inserting the new types after the old types but before the other API functions. It's a code generator problem and doesn't call for a jump in major version. We hope ;) I think David's hack, which looks to have been committed by Stefan, should fix things up. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
