Hi all, The 1.2 version of NumPy is going to be tagged. There is at least one change I'd like to add: The hasobject member of the PyArray_Descr structure should be renamed to "flags" and converted to a 32-bit integer. What does everybody think about this change? It should have minimal affect except to require a re-compile of extension modules using NumPy. The only people requiring code changes would be those making intimate use of the PyArray_Descr structure instead of using the macros. It's a simple change if there is no major opposition. -Travis
On Fri, Aug 8, 2008 at 7:22 PM, Travis E. Oliphant <oliphant@enthought.com> wrote:
The 1.2 version of NumPy is going to be tagged. There is at least one change I'd like to add: The hasobject member of the PyArray_Descr structure should be renamed to "flags" and converted to a 32-bit integer.
What does everybody think about this change? It should have minimal affect except to require a re-compile of extension modules using NumPy. The only people requiring code changes would be those making intimate use of the PyArray_Descr structure instead of using the macros.
+1 I am going to hold off on tagging 1.2.0b1 until Monday. This way if anyone has any objections to this change, they will have a few days to discuss this. If there are no major objections by Monday, go ahead and make the change and I will tag the beta release. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
Travis, Stéfan, I missed Travis mail previously. Are you *really* sure you want force all C code which uses numpy arrays to be recompiled? If you mean that all your matplotlib/PIL/pyopengl/etc users are going to have to make a co-ordinated upgrade, then this seems to be a grave mistake. Does Stéfan's patch fix this problem to avoid all C code being recompiled? A co-ordinated recompile of *all* C code using numpy is certainly not a minimal effect! I really hope you can find a way around the recompiling, it is really a problem for anyone trying to distribute code as a python module for windows. Jon Travis E. Oliphant wrote:
Hi all,
The 1.2 version of NumPy is going to be tagged. There is at least one change I'd like to add: The hasobject member of the PyArray_Descr structure should be renamed to "flags" and converted to a 32-bit integer.
What does everybody think about this change? It should have minimal affect except to require a re-compile of extension modules using NumPy. The only people requiring code changes would be those making intimate use of the PyArray_Descr structure instead of using the macros.
It's a simple change if there is no major opposition.
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Aug 16, 2008 at 04:34, Jon Wright <wright@esrf.fr> wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force all C code which uses numpy arrays to be recompiled? If you mean that all your matplotlib/PIL/pyopengl/etc users are going to have to make a co-ordinated upgrade, then this seems to be a grave mistake.
FWIW, neither PIL nor PyOpenGL have C code which uses numpy arrays, so they are entirely unaffected. And this does not require an *upgrade* of the actually affected packages, just a rebuild of the binary. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
On Sat, Aug 16, 2008 at 04:34, Jon Wright <wright@esrf.fr> wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force all C code which uses numpy arrays to be recompiled? If you mean that all your matplotlib/PIL/pyopengl/etc users are going to have to make a co-ordinated upgrade, then this seems to be a grave mistake.
FWIW, neither PIL nor PyOpenGL have C code which uses numpy arrays, so they are entirely unaffected. And this does not require an *upgrade* of the actually affected packages, just a rebuild of the binary.
I'll also point out that PEP 3118 will make this unnecessary in the future for many applications. http://www.python.org/dev/peps/pep-3118/ From what I can tell ( http://svn.python.org/view?rev=61491&view=rev ), this is already in Python 2.6. -Andrew
Andrew Straw wrote:
Robert Kern wrote:
On Sat, Aug 16, 2008 at 04:34, Jon Wright <wright@esrf.fr> wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force all C code which uses numpy arrays to be recompiled? If you mean that all your matplotlib/PIL/pyopengl/etc users are going to have to make a co-ordinated upgrade, then this seems to be a grave mistake.
FWIW, neither PIL nor PyOpenGL have C code which uses numpy arrays, so they are entirely unaffected. And this does not require an *upgrade* of the actually affected packages, just a rebuild of the binary.
I'll also point out that PEP 3118 will make this unnecessary in the future for many applications. http://www.python.org/dev/peps/pep-3118/
From what I can tell ( http://svn.python.org/view?rev=61491&view=rev ), this is already in Python 2.6.
I just tried to make use of this functionality with the Python 2.6 beta 2 release and numpy svn trunk. Everything is present in Python itself, but numpy doesn't yet support the PEP. -Andrew
On Sat, Aug 16, 2008 at 3:43 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Aug 16, 2008 at 04:34, Jon Wright <wright@esrf.fr> wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force all C code which uses numpy arrays to be recompiled? If you mean that all your matplotlib/PIL/pyopengl/etc users are going to have to make a co-ordinated upgrade, then this seems to be a grave mistake.
FWIW, neither PIL nor PyOpenGL have C code which uses numpy arrays, so they are entirely unaffected. And this does not require an *upgrade* of the actually affected packages, just a rebuild of the binary.
What about SAGE, MPL, PyTables, and friends? I don't really know what all depends on Numpy at this point, but I think Ron's point about Windows packages is a good one. On Linux I just compile all these from svn anyway, but I suspect windows users mostly depend on precompiled packages. And this probably also effects packagers for Linux binary distros like ubuntu and fedora also, as they have to recompile all those packages and keep the dependencies straight. True, most of the packages trail numpy development by some time, but that is also an arguement against the urge to push things in early. Chuck
Robert Kern wrote:
FWIW, neither PIL nor PyOpenGL have C code which uses numpy arrays, so they are entirely unaffected.
OK, so here are some projects which might notice a 1.2 installation, in as much as they turn up on a google code search for: #include "numpy/arrayobject.h" -scipy -enthought ... so one might imagine their programs will suddenly stop working. Based on the first 40 of >200 hits, these projects seem to offer binary windows downloads and have a C source which includes numpy/arrayobject.h : PyQwt3d ScientificPython RPy PyTables pygsl VPython bayes-blocks http://forge.pascal-network.org/projects/bblocks/ fdopython http://fdo.osgeo.org For these ones I only found source, so they'd be daft to complain about a program that previously worked just fine has stopped working: neuron (www.neuron.yale.edu) pysl - bridge between python and S-lang BGL - Biggles Graphics Library www.eos.ubc.ca/research/clouds/software.html astronomyworks.googlecode.com pyrap.google.com pyroms.googlecode.com pyamg.googlecode.com mdanalysis.googlecode.com pythoncall - python to matlab interface code.astraw.com/projects/motmot (It is impressive that there are so many users out there, and it turns out that this is a great way to find interesting code.) Even if there turn out to be a lot of duplicates in the >200 hits, already most of those projects have notices saying things like "be sure to get numpy, not Numeric or numarray". Do you want all of them to be delivering a matrix of binaries for different python versions multiplied by numpy <1.1.x versus >1.2.x ? What happens when someone wants to use *two* modules at the time, but one is distributing 1.1 binaries and the other has 1.2? The main reason I changed to numpy was that you stopped doing the Numeric binaries for python2.5. There was no way to distribute my own code for 2.5 without shipping Numeric too, which I didn't want to do, given that you were trying to get everyone to switch. What is the cool new feature that 1.2 has gained which is making all this worthwhile? Are you really 100% certain you need that new feature enough to make all those strangers need to do all that work? Can you give a concrete example of something which is gained by:
"The hasobject member of the PyArray_Descr structure should be renamed to "flags" and converted to a 32-bit integer."
Try to look 12 months into the future and ask yourselves if it was really a good idea to break the ABI. Jon
On Sat, Aug 16, 2008 at 3:02 PM, Jon Wright <wright@esrf.fr> wrote: <snip>
Try to look 12 months into the future and ask yourselves if it was really a good idea to break the ABI.
I'm slowly coming to the conviction that there should be no C-ABI changes in 1.2. And maybe not in 1.3 either, instead we should work on fixing bugs and beating the code into shape. The selling point of 1.1.x is python 2.3 compatibility, the selling point of 1.2.x should be bug fixes and cleanups, including testing and documentation. ABI changes should be scheduled for 2.0. At some point down the road we can start thinking of Python 3.0, but I don't expect Python 3.0 adoption to be quick, it is a big step and a lot of projects will have to make the transition before it becomes compelling. Chuck
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris <charlesr.harris@gmail.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, but we keep having those discussions, and I still don't understand whether there is a consensus here. Breaking a bit or breaking a lot is the same: we broke API in 1.1, we are breaking in 1.2, will we break in 1.3 ? If we we will always break when we "need" to, at least I would like to be clear on that. I personally think it is wrong to break API and ABI. I don't care about the version where we break; I think the focus on the version is a bit misplaced, because in python (and numpy), the version is different from what is the norm in other big open source projects anyway (in any open source project I know, breaking between N.x and N.x+1 is a bug). The focus should be the period of time you can rely on a stable API (and ABI). Changing the API every three months sounds really wrong to me, whatever the version is. That's something that most if not all successful open source projects used by other ones do (gtk, qt, kde, etc...). I don't see what's so different in numpy so that we could afford doing something those other projects can't. cheers, David
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris <charlesr.harris@gmail.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 ?
On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau <cournape@gmail.com>wrote:
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris <charlesr.harris@gmail.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. Chuck
2008/8/17 Charles R Harris <charlesr.harris@gmail.com>:
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.
I believe that is more or less accurate; Travis can confirm. With the new API version counter in place (it's not, btw -- still up for review), we should be able to keep the breakage to a minimum from here onwards. Unfortunately, I don't see an easy way to avoid it for the 1.2 release. Regards Stéfan
On Sun, Aug 17, 2008 at 12:51 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
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.
But that's a totally different matter. You can add functionalities and not breaking API or ABI. I mean gtk 2 exists for maybe 7 or 8 years now, and a program linked against gtk 2.0.0 can run with gtk 2.12.0, but gtk 2.12.0 certainly is different than 2.0.0. Having a policy about API/ABI stability does not mean we can't change anything. cheers, David
Charles R Harris wrote:
On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote:
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote: > On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris > <charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.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. -Travis
On Mon, Aug 18, 2008 at 10:26 AM, Travis E. Oliphant <oliphant@enthought.com
wrote:
Charles R Harris wrote:
On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote:
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote: > On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris > <charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.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. Chuck
On Mon, Aug 18, 2008 at 10:04 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
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.
Adding a member to a struct does not break ABI as long as the struct is not used in another struct (or you could use something like C++ pimpl: using struct inside struct is how inheritence is implemented by most compilers I believe in C++, and pimpl is often used to add members to inherited classes).
We also need to distinquish between internal and external ABI's.
What is internal and external ABI ?
One way to avoid the problems like this is to put some "spares" in the original structure to reserve space for future enhancements.
If pimpl can be used in C python, I think it is better to use this than reserving space. http://en.wikipedia.org/wiki/Opaque_pointer#C.2B.2B I still don't know enough about C internals of numpy, but I believe both would break a lot of code at the API level.
It can also be useful to use getters and setters, ala C++, in the interface.
Yes, that's basically what the pimpl principle is about. But it breaks ABI and API (see gtk 3.0 discussion for the same kind of problems). http://tirania.org/blog/archive/2008/Jul-14.html http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B cheers, David
David Cournapeau wrote:
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris <charlesr.harris@gmail.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 ?
No, we could do that. -Travis
Jon Wright wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force all C code which uses numpy arrays to be recompiled? Re-compilation is necessary at some point. We have not required recompilation for a long time now. Yes, it is a pain for distribution, but those who don't want to re-compile can point people to 1.1.1 which will still work until they make a new release compiled against the newer NumPy.
I would encourage people to make use of things like Python(x,y), EPD, and SAGE for their distribution needs. -Travis
On Sat, Aug 16, 2008 at 10:47 AM, Travis E. Oliphant <oliphant@enthought.com> wrote:
Re-compilation is necessary at some point. We have not required recompilation for a long time now. Yes, it is a pain for distribution, but those who don't want to re-compile can point people to 1.1.1 which will still work until they make a new release compiled against the newer NumPy.
Does that mean we will continue breaking the ABI from time to time during the 1.* cycle ? cheers, David
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for this change? If it only means everyone recompiles, it is hard to see what we, as users, are gaining by doing that. Thanks, Jon
On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright <wright@esrf.fr> wrote:
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for this change? If it only means everyone recompiles, it is hard to see what we, as users, are gaining by doing that.
Turns out that ipython needs to be recompiled also because of the newly added version checking. Chuck
On Sat, Aug 16, 2008 at 11:56 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright <wright@esrf.fr> wrote:
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for this change? If it only means everyone recompiles, it is hard to see what we, as users, are gaining by doing that.
Turns out that ipython needs to be recompiled also because of the newly added version checking.
Looks like there is a bug in the new API version tracking:
import numpy as np RuntimeError: module compiled against version 1000009 of C-API but this version of numpy is 100000a Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/site-packages/numpy/__init__.py", line 132, in <module> import add_newdocs File "/usr/lib/python2.5/site-packages/numpy/add_newdocs.py", line 9, in <module> from lib import add_newdoc File "/usr/lib/python2.5/site-packages/numpy/lib/__init__.py", line 4, in <module> from type_check import * File "/usr/lib/python2.5/site-packages/numpy/lib/type_check.py", line 8, in <module> import numpy.core.numeric as _nx File "/usr/lib/python2.5/site-packages/numpy/core/__init__.py", line 19, in <module> import scalarmath ImportError: numpy.core.multiarray failed to import
Chuck
On Sat, Aug 16, 2008 at 12:05 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Aug 16, 2008 at 11:56 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright <wright@esrf.fr> wrote:
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for this change? If it only means everyone recompiles, it is hard to see what we, as users, are gaining by doing that.
Turns out that ipython needs to be recompiled also because of the newly added version checking.
Looks like there is a bug in the new API version tracking:
import numpy as np RuntimeError: module compiled against version 1000009 of C-API but this version of numpy is 100000a Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/site-packages/numpy/__init__.py", line 132, in <module> import add_newdocs File "/usr/lib/python2.5/site-packages/numpy/add_newdocs.py", line 9, in <module> from lib import add_newdoc File "/usr/lib/python2.5/site-packages/numpy/lib/__init__.py", line 4, in <module> from type_check import * File "/usr/lib/python2.5/site-packages/numpy/lib/type_check.py", line 8, in <module> import numpy.core.numeric as _nx File "/usr/lib/python2.5/site-packages/numpy/core/__init__.py", line 19, in <module> import scalarmath ImportError: numpy.core.multiarray failed to import
False alarm. I needed to remove the build directory first. Chuck
On Sat, Aug 16, 2008 at 10:56 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Turns out that ipython needs to be recompiled also because of the newly added version checking.
I'm sorry, can you clarify this? ipython has no C code at all, so I'm not sure what you mean here. Cheers, f
On Sat, Aug 16, 2008 at 1:26 PM, Fernando Perez <fperez.net@gmail.com>wrote:
On Sat, Aug 16, 2008 at 10:56 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Turns out that ipython needs to be recompiled also because of the newly added version checking.
I'm sorry, can you clarify this? ipython has no C code at all, so I'm not sure what you mean here.
It was a false alarm. I was calling ipython with pylab and MPL needs to be recompiled. Chuck
On Sat, Aug 16, 2008 at 12:44 PM, Jon Wright <wright@esrf.fr> wrote:
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for this change? If it only means everyone recompiles, it is hard to see what we, as users, are gaining by doing that.
Breaking the ABI forces users to recompile, that's pretty much the definition of ABI breaks. Unfortunately, up to now, we did not have a mechanism to make the difference between extending the API (which can be done without breaking the ABI if done carefully) and breaking the API (which induces ABI breakage). Hopefully, once this is in place, we won't have to do it anymore. cheers, David
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time during the 1.* cycle ?
Jon Wright wrote:
Can someone help me to understand me what is the compelling reason for this change? If it only means everyone recompiles, it is hard to see what we, as users, are gaining by doing that.
As another NumPy user, and developer on another python project using Numeric/numpy at the C level, I had much the same thought. For our users who compile from source or use their Linux distribution's packages this isn't that big problem (the Linux packagers however may disagree!). However, to support Windows users, this means that in addition to providing one installation exe per version of python, we'd also need to provide separate versions for numpy 1.1 and 1.2. I am also not looking forward to the additional up front effort to reorganise our build system to cope with two versions of numpy. I imagine most 3rd party projects which use the NumPy at the C level will have similar views, and quite likely many of them are currently blissfully unaware of this impending API breakage, as I would have expect more comments. (I would have replied earlier but I had to track down which email address I was subscribed to this list with.) I really can't see why NumPy 1.2 is going to break the C-API compatibility for something that sounds so trivial as renaming the "hasobject" member of the PyArray_Descr structure to "flags". This doesn't even add any new functionality! I do understand that the API will have to evolve at some point, and Stéfan van der Walt's version numbering scheme sounds like a sensible change to make when you do change the C-API. I'm just questioning the rational for breaking the C-API in NumPy 1.2 for what seems to me a trivial change. I don't know if this constitutes "major opposition", but is keeping the same C-API for NumPy 1.2 unchanged still a possibility? Please? Thank you, Peter
On Sun, Aug 17, 2008 at 5:33 AM, Peter <numpy-discussion@maubp.freeserve.co.uk> wrote:
I don't know if this constitutes "major opposition", but is keeping the same C-API for NumPy 1.2 unchanged still a possibility? Please?
Sorry I haven't commented on this yet; I have been busy and am still thinking about the issue. This note is just to say that we are taking this concern *very* seriously and will be discussing it in detail over the next few days at the SciPy conference. We will be looking more closely at the proposed code changes, discussing whether we really need to change the C-API, and if we do need to change the C-API (either now or in the future) how we should handle these sort of changes. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
participants (10)
-
Andrew Straw -
Charles R Harris -
David Cournapeau -
Fernando Perez -
Jarrod Millman -
Jon Wright -
Peter -
Robert Kern -
Stéfan van der Walt -
Travis E. Oliphant