[Numpy-discussion] C-API change for 1.2
Charles R Harris
Mon Aug 18 12:04:36 CDT 2008
On Mon, Aug 18, 2008 at 10:26 AM, Travis E. Oliphant <email@example.com
> Charles R Harris wrote:
> > On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau <firstname.lastname@example.org
> > <mailto:email@example.com>> wrote:
> > On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau
> > <firstname.lastname@example.org <mailto:email@example.com>> wrote:
> > > On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris
> > > <firstname.lastname@example.org <mailto:email@example.com>>
> > wrote:
> > >>
> > >> I'm slowly coming to the conviction that there should be no
> > C-ABI changes in
> > >> 1.2.
> > >
> > > It does not make sense to revert those changes anymore,
> > Actually, I did not follow the discussion when this change happened,
> > but it does not look difficult to change the code such as we do not
> > break the ABI. Instead of replacing the flag, we can put it at the
> > end, and deprecate (but not remove) the old one.
> > Would anyone be strongly against that ?
> > I have nothing against extensions when they can be made to serve. If a
> > dictionary gets added to ndarrays I hope it is done that way, likewise
> > for generalized ufuncs. In the present case I think Travis wants to
> > preserve the functionality while changing the name and type, and that
> > doesn't really fit the extension model. But I might be wrong about that.
> The problem was that I didn't break ABI compatibility at 1.0. I new the
> char was too small to hold what the field had really become (a flag
> field). I had intended for 1.1 to be a potential ABI breakage, but
> this was changed when the release strategy changed.
> But, there is no real functionality added by changing the ABI at this
> point. I'm just looking to the future, but I can be convinced that it's
> too late.
> What about the version number changes.
You mean the version number tracking ABI changes? I think it will be useful
if/when we do break the ABI so that people will be informed, until then, we
could leave it out. If you could figure out how to add a new flags field
without affecting the old one or requiring existion applications to be
recompiled, that would be good. We also need to distinquish between internal
and external ABI's. One way to avoid the problems like this is to put some
"spares" in the original structure to reserve space for future enhancements.
It can also be useful to use getters and setters, ala C++, in the interface.
These would be actual functions instead of macros and hide changes to the
structures, just accepting pointers that can be downcast.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion