[SciPy-dev] Renaming scipy_core ???
schofield at ftw.at
Sun Jan 1 19:45:26 CST 2006
On 01/01/2006, at 11:58 PM, Fernando Perez wrote:
> Travis Oliphant wrote:
>> sci (arrlab, scicore)/
> I'm +0.5 on scicore: I think it emphasizes the fact that this
> constitutes the
> necessary core functionality for scipy, without any of the current
> problems. The following is a little experiment, to see how a blurb
> would read
> (remove the weave reference as needed). Feel free to s/scicore/
> to see how it would read:
> """scicore is a package for array-based numerical computing in Python.
> It provides a collection of modules useful for a wide variety of
> tasks, similar in spirit to the basic functionality of systems such
> as Matlab
> or IDL. At its center is a flexible array type which can be very
> useful even
> for non-scientific tasks that interface with arrays in C libraries.
> The scicore package consists of:
> - ndarray: a package exposing a flexible datatype to efficiently
> n-dimensional arrays. Such objects are implemented as C extensions
> support array element-wise arithmetic and other mathematical
> While they are conceptually similar to the arrays of languages like
> they are in fact much more capable objects, as their contents can
> consist of
> arbitrary python objects and they have very rich indexing, data
> access and
> low-level maninpulation capabilities.
> - f2py: ...
> The scicore package can be installed on any standard python
> distribution, and
> it has no other dependencies for installation than Python itself
> (and a C
> compiler for a source-based install, as there is extension code in
> it). At
> runtime, some of its components do require the presence of
> compilers (f2py
> needs a Fortran compiler, while weave needs a C++ one), but these
> are not
> needed unless you explicitly import and use f2py or weave.
> The scipy package builds on top of scicore, to expose a large
> collection of
> algorithms and libraries for many tasks in scientific computing.
> scipy wraps
> many well-known and field-tested Fortran and C libraries, as well
> as providing
> new routines written both in C and in Python.
> Just a little experiment in language :)
>> ->numpy (ndarray, narray)/
> -1 on 'numpy': if at some point in the future this is considered a
> for the stdlib, I don't think we want anything with a 'py' suffix
> in the
> package name (not a single module in the stdlib ends in 'py' today,
> except for
> I also don't want to have to explain to anybody "well, this isn't
> really the
> old numpy, it's the new numpy, which was written by the guy who was
> maintaining the old numpy, but it's a new code, and it also has
> features from
> numarray, so it's like the old numpy + numarray + better, but it's
> numpy again. Easy, no?" Really, I don't.
> +1 on 'ndarray', because it emphasizes the fact that these are
> very flexible (esp. with all the recent enhancements) N-dimensional
> structures. In that sense, 'narray' has a stronger hint of 'n for
> while Travis has shown that these objects can be much more than
> Fortran-type arrays.
> I also think ndarray goes well as an extension to the 'array'
> module in the
> stdlib. They are, after all, conceptually close.
I'm with Fernando on this, for all the same reasons. So:
+1 on 'ndarray' for the basic array module.
+1 on 'scicore' for the whole package.
+1 on moving weave to scipy, to keep scicore lean and mean ;)
More information about the Scipy-dev