On Fri, 25 Mar 2005, Michiel Jan Laurens de Hoon wrote:
Pearu Peterson wrote:
I got an impression from earlier threads that scipy_distutils will be included to scipy_base. So, I am proposing to use scipy_distutils tools and our scipy experience for dealing with this issue, scipy.lib.lapack would be a good working prototype here.
Have you tried integrating scipy_distutils with Python's distutils? My guess is that Python's distutils can benefit from what is in scipy_distutils, particularly the parts dealing with C compilers. A clean integration will also prevent duplicated code, avoids Pearu having to keep scipy_distutils up to date with Python's distutils, and will enlarge the number of potential users. Having two distutils packages seems to be too much of a good thing.
No, I have not. Though a year or so ago there was a discussion about this in distutils list, mainly for adding Fortran compiler support to distutils. At the time I didn't have resources to push scipy_distutils features to distutils and even less so for now. So, one can think that scipy_distutils is an extension to distutils, though it also includes few bug fixes for older distutils. On the other hand, since Scipy supports Python starting at 2.2 then it cannot relay much on new features added to distutils of later Python versions. Instead, if these features happen to be useful for Scipy then they are backported for Python 2.2 through implementing them in scipy_distutils. "Luckily", there are not much such features as scipy_distutils has evolved with new very useful features much quicker than distutils. But, for Numeric3, scipy.distutils would be a perfect place to clean up scipy_distutils a bit, e.g. removing some obsolete features and assuming that Numeric3 will support Python 2.3 and up. Based on that, integrating scipy_distutils features to standard distutils can be made less pain if someone decides to do that. Pearu