[PYTHON MATRIX-SIG] Final matrix object renaming and packaging

Hinsen Konrad hinsenk@ere.umontreal.ca
Tue, 16 Jan 1996 12:17:41 -0500

   I feel strongly that the Matrix module should export it's C interface
   using CObjects so that modules using matrices to not require that any
   of the matrix software be statically linked.  In my distribution of

I agree in principle, but that doesn't have to happen in the
first beta release.

   Are these imported by Numeric, or would the user be importing these?
   Is the current built-in array module going away?  If not, then there
   is a name conflict on case-insensitive file systems.  I like the idea

Why? The current "array" in a C module, so "import Array" will
never load it, independent of the file name conventions. Which
means that "import Array" will always obtain an external module,
and as long as ours is the only one, it hardly matters if it
is called "Array.py" or "array.py".

   importing Matrix and Array.  Is there any reason for the user to
   import Array directly?  I am strongly opposed to using "Array" unless

Certainly, e.g. if the user doesn't want anything else. Besides, as I
pointed out in my last mail, a general "Numeric" module is not such a
terrific idea.

   So someone who wants to create a matrix object will do something like:

     import Numeric


Speaking about constructors... I still prefer (strongly) more
meaningful names, like IntegerMatrix. Noone should be forced
to learn these silly type codes for standard applications.

Konrad Hinsen                     | E-Mail: hinsenk@ere.umontreal.ca
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. Centre-Ville     | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)

MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org