[Numpy-discussion] rc1 update

Travis E. Oliphant oliphant@enthought....
Thu Aug 28 09:48:16 CDT 2008

Andrew Straw wrote:
> Joining the party late, here, so I don't know how much has already been
> said... Particularly in favor of renaming NPY_VERSION. What's the benefit?
> I'm -1 on removing the name NPY_VERSION. It would cause unnecessary
> breakage.
> I'm -0 on defining an additional NPY_ABI_VERSION to equal NPY_VERSION.
> It just seems unnecessary to me. Won't a comment do, e.g. /* We wanted
> to name this NPY_ABI_VERSION, but it was already NPY_VERSION since pre
> 1.0, so we're sticking with it. (Until 1.2, it also served a dual role
> as NPY_API_VERSION, when we added that, below.) */ ?
> I'm +0 on renaming the recently added NPY_FEATURE_VERSION to
> NPY_API_VERSION. I don't care what it's called, really.
> Since A) this is a C developer thing only (aka people who should know
> what they're doing), B) there is already IMO fairly good documentation
> immediately above the NPY_VERSION and NPY_FEATURE_VERSION in the header
> file, and C) very little impetus for anyone to actually directly use
> NPY_VERSION anyway (there's a runtime ABI check during import_array()
> which is the most important thing -- it checks at runtime if the compile
> time ABI version of the caller and numpy itself are the same), I think
> it's best to leave NPY_VERSION as NPY_VERSION.
> The only code that I know of that currently explicitly uses NPY_VERSION
> is C preprocessor tests for which C API to use -- from now, new code
> being written will check the new NPY_FEATURE_VERSION (or NPY_API_VERSION
> or whatever it ends up being called) for API features. Anyone updating
> old code will already have a bit of additional complexity to deal with,
> and I want to minimize the amount of additional complexity. We don't
> want a rat's nest of C preprossor #ifdefs as people track the numpy
> version checking defines. Given the addition of NPY_FEATURE_VERSION,
> code that's already been written with explicit NPY_VERSION checks for
> API information is already going to become outdated, but as long as we
> keep the NPY_VERSION name, at least it won't break or require another
> level of complexity to maintain forward compatibility.

+1 on what Andrew said.


More information about the Numpy-discussion mailing list