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. -Travis _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
