On Mon, Jan 06, 2003 at 07:29:15PM -0500, Perry Greenfield wrote:
> The main disadvantages I see so far are:
>> 1) One will either have to change import statements in old code
> to match the new style (a pain, but generally changing imports
> is not terribly difficult since they are easy to identify) or
> explicitly add the path to each 3rd party module to Python
> Path (or some equivalent).
I think this should be regarded as a minor annoyance compared with the
advantages of making numarray a package. In addition, the introduction of
numarray as substitute of Numeric can justify some re-code on existing
applications.
> 2) If numarray were accepted into the Python Standard Library, it
> would be the first case (as far as I can tell) of a standard
> library package where we would expect to add sub modules to
> it (e.g., FFT)). Normally these would not be distributed with
> the standard library, so some general mechanism will be needed
> to allow numarray to find 3rd party packages outside of the
> Python directory structure. For example, I don't think we can
> require having people install FFT in the Standard Library
> directory structure after Python is installed. Rather, we would
> probably have numarray look for extension modules in a standard
> named site-packages directory (or site-numarray?) or otherwise
> check a numarraypath environmental variable so that
> import numarray.FFT works properly. Perhaps others have ideas
> about how to best handle this.
>
Great. I would be glad to see a package containing numarray kernel in order
to allow aplications to use their core features, and have a mechanism to add
3rd party packages. In particular, having something similar to site-numarray
to install these packages can be quite neat. In fact, I was pondering to
include a subset of numarray in the PyTables package (it only needs the
numarray core functionality), but if this reorganization takes place, I
would not need to do that anymore.
> Any other issues being overlooked?
Yeah. In case you decide to break numarray in several modules, which would
be the granularity of the separation. My opinion goes to have a reduced core
with basic functionality (to maximize the chances to be included in the
Pyhton Standard Library, but also to allow an easy entry for people who may
wish to use this functionality) and then different, small, 3rd party
packages, but perhaps this is also the most laborious solution.
--
Francesc Alted PGP KeyID: 0x61C8C11F