Re: [Numpy-discussion] rc1 update
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
On Thu, Aug 28, 2008 at 7:48 AM, Travis E. Oliphant <oliphant@enthought.com> wrote:
+1 on what Andrew said.
I don't really care that much, but I do think API is better than FEATURE. I would think that there may be times when we change the API but not the features (e.g., renaming something). I won't bring this up again, so if no one else finds this compelling consider it dropped. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
Jarrod Millman wrote:
On Thu, Aug 28, 2008 at 7:48 AM, Travis E. Oliphant <oliphant@enthought.com> wrote:
+1 on what Andrew said.
I don't really care that much, but I do think API is better than FEATURE. I would think that there may be times when we change the API but not the features (e.g., renaming something). I won't bring this up again, so if no one else finds this compelling consider it dropped.
As I said, I'm +0 on that aspect. So I guess that makes Travis +0, too. ;)
2008/8/28 Andrew Straw <strawman@astraw.com>:
Jarrod Millman wrote:
On Thu, Aug 28, 2008 at 7:48 AM, Travis E. Oliphant <oliphant@enthought.com> wrote:
+1 on what Andrew said.
I don't really care that much, but I do think API is better than FEATURE. I would think that there may be times when we change the API but not the features (e.g., renaming something). I won't bring this up again, so if no one else finds this compelling consider it dropped.
Feel free to change it -- I don't mind. Cheers Stéfan
participants (4)
-
Andrew Straw -
Jarrod Millman -
Stéfan van der Walt -
Travis E. Oliphant