[Numpy-discussion] [numarray] packaging and names

[Perry Greenfield]

There was general consensus that numarray should be organized as a
package. We are about to start doing so. It does raise some
issues (and opportunities) however.

1) What should the package be called? numarray is a possiblity, 
but we have an opportunity to take a different approach. For 
example if we could name the package "array" (unfortunately,
we can't) then the following becomes possible (these are just
examples, we haven't settled on any naming scheme yet).

from array.numeric import * # instead of "from numarray import *"
import array.fft
import array.records # currently recarray

Since array is not avaible (there is already an array module
in the Python Standard Library) what are the alternatives?

Here are some:

num
numarray
arr
arrays
ndarray

I've polled people locally and arrays and ndarray were the most
popular, but there doesn't seem to be a clear winner. I tend toward
arr somewhat because of the brevity but do realize it isn't
terribly descriptive. The drawback of "arrays" is that it may be
visually confused with array.

2) What to call the package components?

Locally the favorites were

numarray --> numeric
recarray --> records
chararray--> strings (but since we plan to implement PyObject arrays
                      there is a possibilty of real Python string arrays)
ndarray  --> generic (or base)

3) Where to place 3rd party array extension modules (by that I 
mean all those not distributed with numarray)? Should 
they go in the package directory? I'd prefer that they go
into a separate directory from the things that are part
of the standard numarray distribution (a site-packages
equivalent in the package?)

4) We would likely also include in the package
numarray.py, recarray.py, chararray.py, ndarray.py
so that if the package was added to the path, the current imports
would continue to work. This is intended as a short-term measure
(i.e., they are deprecated and will disappear at version 1.0, or
earlier). We may also keep these files at the current nummarray
interface so that some of the software we currently distribute
does not need to change immediately to match the changes we have been
talking about.

We realize that these are big changes, but if we move to a package
structure, we ought to think about what makes the most sense (and if
it is any comfort, we suffer the consequences of change more than
anyone else). Better now than later.

Screams?

Perry