[MATRIX-SIG] NumPy in the Python 1.5 era

[Konrad Hinsen]

> KH> With the new package feature in 1.5, we could turn NumPy into a package
> KH> again (veterans may remember that one alpha release used ni-based packages).
> KH> This obviously raises the question of compatibility. My suggestion is
> KH> to keep the current modules, but provide an alternate arrangement as
> KH> a package, and add eventual new modules only to that package. In other
> KH> words, we would still have module/package Numeric with all its functions,
> KH> but the other modules (LinearAlgebra etc.) would be available as
> KH> modules within Numeric, as well as stand-alone modules for compatibility.
> KH> This would cost only minor modifications plus a few links (no duplicate
> KH> code). Any comments?
> 
> My only comment is that I'm not very wedded to backward compatibility.
> If NumPy can be presented as a Python-1.5 package in a neat and generic
> fashion, I would be perfectly happy if that were the *only* (Unix)
> distribution format.

Python 1.5 packages are not really a distribution format. The name
"package" is a bit confusing since it has been used for two distinct
concepts:

1) A distribution unit of modules.
2) A hierarchy of modules.

NumPy already is a package in the first sense, and I think everyone
agrees that making this package easier to install and use is a Good Thing.
This would have no (well, almost no) effect on code that relies on it.

Turning NumPy into a hierarchy of modules (rather than a set of
parallel modules) is something else, and would require a change in all
other modules and scripts using NumPy. I am not a big fan of backwards
compatibility either, but a new release that would break most existing
code would probably find little acceptance. That's why I propose, at
least for a transition period, to make modules available both at the
top level (for compatibility) and as submodules of Numeric (for new
development).

> I like that part about volunteering.  I haven't really studied the
> new 1.5 package facility, so can't comment on it yet.  Your idea for
> exposing the C API to other dynamically loaded modules sounds plausible.

And it's totally independent of the package question - in fact, it involves
major changes only in the C header files.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

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