Re: [Numpy-discussion] package vs module

[Konrad H. <hi...@cn...>]

Perry Greenfield <pe...@st...> writes:

> Back in December the issue of whether numarray should be a package
> potentially reduces name collision issues in general. Most feel
> it is a cleaner way to organize the software (at least based on
> the feedback so far).

I agree. We have discussed converting NumPy into a package a few times
in the past, the major argument against it was compatibility issues.
Numarray will require some changes to import statements anyway, so
this seems the right time to make the change.

> 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

If you plan to unbundle FFT etc. from numarray, then I would prefer a
different naming scheme: numarray being just numarray, and some other
package name grouping together the other modules. That is not only a
question of installation, but also of general maintenance and of
clarity for users. I see the Python package system as a tree:
everything inside a package belongs together, is distributed together
and is maintained by the same people.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------