Hi Travis, I have committed scipy.{distutils,base} to Numeric3 CVS repository. scipy.distutils is a reviewed version of scipy_distutils and as one of its new features there is Configuration class that allows one to write much simpler setup.py files for subpackages. See setup.py files under Numeric3/scipy directory for examples. scipy.base is a very minimal copy of scipy_base plus ndarray modules. When using setup_scipy.py for building, the ndarray package is installed as scipy.base and from scipy.base import * should work equivalently to from ndarray import * for instance. I have used information from Numeric3/setup.py to implement Numeric3/scipy/base/setup.py and it should be updated whenever Numeric3/setup.py is changed. However, I would recommend start using scipy.base instead of ndarray as using both may cause unexpected behaviour when installed ndarray is older than scipy.base installation (see [*]). In Numeric3 CVS repository that would mean replacing setup.py with setup_scipy.py and any modification to ndarray setup scripts should be done in scipy/base/setup.py. We can apply this step whenever you feel confident with new setup.py files. Let me know if you have any troubles with them. To clean up Numeric3 CVS repository completely then Include, Src, Lib, CodeGenerators directories should be moved under the scipy/base directory. However, this step can be omitted if you would prefer working with files at the top directory of Numeric3. Current setup.py scripts fully support this approach as well. There are also few open issues and questions. First, how to name Numeric3 project when it installs scipy.base, scipy.distutils, Numeric packages, etc? This name will be used when creating source distributions and also as part of the path where header files will be installed. At the moment setup_scipy.py uses the name 'ndarray'. And so `setup_scipy.py sdist`, for example, produces ndarray-30.0.tar.gz file; `setup_scipy.py install` installs header files under <prefix>/include/ndarray/ directory. Though this is fine with me, I am not sure that this is an ideal situation. I think we should choose the name now and stick to it forever, especially since 3rd party extension modules need to know where to look for ndarray header files. This name cannot be 'numarray', obviously, but there are options like 'ndarray', 'numpy', and may be others. In fact, 'Numeric' (with version 3x.x) would be also an option but that would be certainly cause some problems when one wants both Numeric 2x.x and Numeric 3x.x to be installed in the system, the header files would end up in the same directory, for instance. As a workaround, we could force installing Numeric3 header files to <prefix>/include/Numeric/3/ or something. I acctually like this idea but I wonder what other think about this. Second, is it already possible to use ndarray C/API as a replacement of Numeric C/API, i.e. would simple replacement of #include "Numeric/arrayobject.h" with #include "ndarray/arrayobject.h" work? And if not, will it ever be? This would be interesting to know as an extension writer. [*] Due to keeping changes to Numeric3 sources minimal, scipy.base multiarray and umath modules first try to import ndarray and then scipy.base whenever ndarray is missing. One should remove ndarray installation from the system before using scipy.base. Regards, Pearu
Pearu Peterson wrote:
Hi Travis,
I have committed scipy.{distutils,base} to Numeric3 CVS repository. scipy.distutils is a reviewed version of scipy_distutils and as one of its new features there is Configuration class that allows one to write much simpler setup.py files for subpackages. See setup.py files under Numeric3/scipy directory for examples. scipy.base is a very minimal copy of scipy_base plus ndarray modules.
Thank you, thank you for your help with this.
When using setup_scipy.py for building, the ndarray package is installed as scipy.base and
from scipy.base import *
should work equivalently to
from ndarray import *
for instance.
I don't like from ndarray import *. It's only been a place-holder. Let's get rid of it as soon as possible.
To clean up Numeric3 CVS repository completely then Include, Src, Lib, CodeGenerators directories should be moved under the scipy/base directory. However, this step can be omitted if you would prefer working with files at the top directory of Numeric3.
I have no preference here. Whatever works best.
First, how to name Numeric3 project when it installs scipy.base, scipy.distutils, Numeric packages, etc? This name will be used when creating source distributions and also as part of the path where header files will be installed. At the moment setup_scipy.py uses the name 'ndarray'.
I don't like the name ndarray -- it's too limiting. Why not scipy_core?
In fact, 'Numeric' (with version 3x.x) would be also an option but that would be certainly cause some problems when one wants both Numeric 2x.x and Numeric 3x.x to be installed in the system, the header files would end up in the same directory, for instance. As a workaround, we could force installing Numeric3 header files to <prefix>/include/Numeric/3/ or something. I acctually like this idea but I wonder what other think about this.
How about include/scipy?
Second, is it already possible to use ndarray C/API as a replacement of Numeric C/API, i.e. would simple replacement of
#include "Numeric/arrayobject.h"
with
#include "ndarray/arrayobject.h"
work? And if not, will it ever be? This would be interesting to know as an extension writer.
This should work fine. All of the old C-API is there (there are some new calls, but the old ones should still work). The only issue is that one of the calls (PyArray_Take I think now uses a standardized PyArrayObject * as one of it's arguments instead of a PyObject *). This shouldn't be a problem, since you always had to call it with an array. It's just now more explicit, but could lead to a warning.
[*] Due to keeping changes to Numeric3 sources minimal, scipy.base multiarray and umath modules first try to import ndarray and then scipy.base whenever ndarray is missing. One should remove ndarray installation from the system before using scipy.base.
I don't mind changing the package names entirely at this point. -Travis
On Mon, 11 Apr 2005, Travis Oliphant wrote:
When using setup_scipy.py for building, the ndarray package is installed as scipy.base and
from scipy.base import *
should work equivalently to
from ndarray import *
for instance.
I don't like from ndarray import *. It's only been a place-holder. Let's get rid of it as soon as possible.
Done in CVS.
To clean up Numeric3 CVS repository completely then Include, Src, Lib, CodeGenerators directories should be moved under the scipy/base directory. However, this step can be omitted if you would prefer working with files at the top directory of Numeric3.
I have no preference here. Whatever works best.
Directory Include/ndarray/ is now moved to scipy/base/Include/scipy/base/. I'l move other directories as well.
First, how to name Numeric3 project when it installs scipy.base, scipy.distutils, Numeric packages, etc? This name will be used when creating source distributions and also as part of the path where header files will be installed. At the moment setup_scipy.py uses the name 'ndarray'.
I don't like the name ndarray -- it's too limiting. Why not scipy_core?
In fact, 'Numeric' (with version 3x.x) would be also an option but that would be certainly cause some problems when one wants both Numeric 2x.x and Numeric 3x.x to be installed in the system, the header files would end up in the same directory, for instance. As a workaround, we could force installing Numeric3 header files to <prefix>/include/Numeric/3/ or something. I acctually like this idea but I wonder what other think about this.
How about include/scipy?
Without going into details of distutils restrictions for various options, I found that #include "scipy/base/arrayobject.h" option works best. And the name of the Numeric3 package is now scipy_core. All this is implemented in Numeric3 CVS now.
Second, is it already possible to use ndarray C/API as a replacement of Numeric C/API, i.e. would simple replacement of
#include "Numeric/arrayobject.h"
with
#include "ndarray/arrayobject.h"
work? And if not, will it ever be? This would be interesting to know as an extension writer.
This should work fine.
Great! Thanks, Pearu
participants (3)
-
Pearu Peterson -
pearu＠cens.ioc.ee
-
Travis Oliphant