Re: [Numpy-discussion] C-API change for 1.2
On Sun, Aug 17, 2008 at 5:33 AM, Peter [EMAIL PROTECTED] 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/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
David Cournapeau wrote: On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
Charles R Harris wrote: On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Mon, Aug 18, 2008 at 10:26 AM, Travis E. Oliphant [EMAIL PROTECTED] wrote: Charles R Harris wrote: On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
2008/8/17 Charles R Harris [EMAIL PROTECTED]: 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sun, Aug 17, 2008 at 12:51 AM, Charles R Harris [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 04:34, Jon Wright [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
Robert Kern wrote: On Sat, Aug 16, 2008 at 04:34, Jon Wright [EMAIL PROTECTED] 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=61491view=rev ), this is already in Python 2.6. -Andrew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 3:43 AM, Robert Kern [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 04:34, Jon Wright [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 10:47 AM, Travis E. Oliphant [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 11:56 AM, Charles R Harris [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright [EMAIL PROTECTED] 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 109 of C-API but this version of numpy is 10a 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 12:05 PM, Charles R Harris [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:56 AM, Charles R Harris [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright [EMAIL PROTECTED] 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 109 of C-API but this version of numpy is 10a 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 10:56 AM, Charles R Harris [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 1:26 PM, Fernando Perez [EMAIL PROTECTED]wrote: On Sat, Aug 16, 2008 at 10:56 AM, Charles R Harris [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 12:44 PM, Jon Wright [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 3:02 PM, Jon Wright [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris [EMAIL PROTECTED] 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 ? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau [EMAIL PROTECTED]wrote: On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C-API change for 1.2
On Fri, Aug 8, 2008 at 7:22 PM, Travis E. Oliphant [EMAIL PROTECTED] 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/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] C-API change for 1.2
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
