
Michiel Jan Laurens de Hoon wrote:
While I basically agree with your setup, I think that there is no need to call it scipylite. Sticking to the Numeric structure and names is to the advantage of both current SciPy and current Numerical Python users. The advantage to current Numerical Python users is obvious -- and there are many more of them than of SciPy users. For SciPy users, it is in their best interest that as many people as possible go over to Numeric3, in order to avoid another split in the Numerics community. Now, if I talk with the other pygist or biopython developers and tell them there is a new Numerical Python package which solves some of the issues with the older versions, I have a good chance to convince them to update pygist/biopython to the Numeric3 API. If I tell them that there is a scipylite package that intends to replace Numerical Python: Forget it. It will be ignored. You may not care about pygist or biopython in particular, but developers of other packages will make the same consideration, so you may end up with some numerical / graphics packages working with scipylite and others with Numerical Python 23.8. It's better to get everybody on board.
Secondly, we have confused users more than enough with the Numerical Python / numarray / Numeric3 split. We should not add one more new name to the equation.
Third, there is lots of code out there that imports LinearAlgebra or RandomArray etcetera. Why force our users to go through the trouble of changing those imports? I don't see the benefit to the users.
Finally, the word scipylite has no meaning. As SciPy evolves into a website where scientific software for Python can be downloaded, there will not be a scipy-full nor a scipy-lite.
--Michiel.
It looks to me as though getting numarray/Numeric sorted out, and getting it right, will be sufficient work for now. It's far better to concentrate the limited resources on that and to leave the complexities of SciPy for another day. I wonder about introducing another distribution system (SVN?) when some of us have barely mastered CVS. Colin W.
Travis Oliphant wrote:
Putting the parts of scipy_base together is a good idea. Exactly how to structure this is going to require some thought and need to be coordinated with current scipy.
I want a package that is as easy to install as current Numeric (so the default will have something like lapack_lite). But, this should not handicap nor ignore a speed-conscious user who wants to install ATLAS or take advantage of vendor-supplied libraries.
There should be a way to replace functionality that is clean and does not require editing setup.py files.
Anybody with good ideas about how to do this well is welcome to speak up. Perhaps, the easiest thing to do is to keep the basic Numeric structure (with C-based easy-to-install additions) and call it scipylite (with backwards compatibility provided for Numeric, LinearAlgebra, RandomArray, and MLab names). This also installs the namespace scipy which has a little intelligence in it to determine if you have altas and fortran capabilities installed or not.
Then, provide a scipyatlas package that can be installed to take advantage of atlas and vendor-supplied lapack/blas.
Then, a scipyfortran package that can be installed if you have a fortran compiler which provides the functionality provided by fortran libraries. So, there are three divisions here. Feedback and criticisms encouraged and welcomed.....