If I move things like FFT out of the core and make them separate packages, I am left with a choice: make them real packages, which means their usage would change, or structure the packages so that everything gets installed in the Python search path the way it does now. The first choice is better for the future, walling everything off into namespaces properly. The second choice doesn't break any existing code. The changes involve just namespace issues. Right now all of Numeric is installed as separate top-level modules. The same considerations apply somewhat to Numeric itself. By making the existing Numeric.py into the __init__.py for a Numeric package, nothing would break except imports of Precision and ArrayPrinter, which would have to become Numeric.Precision, etc. How much pain is the future worth?
An important thing to keep in mind is the possibility that part of Numeric.py can become a standard part of Python, this would mean that it has the same status as the string module. This would speak against a package structure for Numeric itself. So if packages are used, the structure should not be a subtree of Numeric. Second thought: Should every module be it's own package? Or should there be a structure so that third party modules can be sorted into this structure (for example sorted by problem domains, math, data, IO, physics/natural science, image processing etc.) One problem is, if some libraries with a broader spectrum are wrapped, like GSL, the sorting becomes obsolete. This would suggest to have a package for every module. I would also say, that it is not easy to aim at complete environment if there is not a refactoring by a maintainer. As long as the modules are only (not meant in a bad way) provided by different authors there will be no kitchen sink application. This would also suggest a package for every module. __Janko
David Ascher writes:
An important thing to keep in mind is the possibility that part of Numeric.py can become a standard part of Python, this would mean that it has the same status as the string module.
Why? Packagizing of the standard library is a long-term goal.
Also in the case of a Numeric package which goes into the standard distribution should the other packages be integrated in the Numeric namespace or build under an external tree in the site-packages directory? I do not know the proposed scheme, is there something written down somewhere? __Janko
Also in the case of a Numeric package which goes into the standard distribution should the other packages be integrated in the Numeric namespace or build under an external tree in the site-packages directory? I do not know the proposed scheme, is there something written down somewhere?
__Janko
I didn't make a proposal; I was trying to gauge whether people would freak at a change that required modification of existing scripts, or not. My thoughts, however, were along the lines of two packages, Numeric and MathPack. Then I would put a substructure under MathPack by subject area. Already, however, we see ugliness on the horizon: the module RandomArray imports both ranlib and a linear algebra package, so we have Package Dependencies and all the glorious ugliness of real life. I'm sure we'd have more in the future. There are competing packages for some things, such as random numbers. Ugh, how to make this easy for a random scientist who drops by...
If I move things like FFT out of the core and make them separate packages, I am left with a choice: make them real packages, which means their usage would change, or structure the packages so that everything gets installed in the Python search path the way it does now.
The first choice is better for the future, walling everything off into namespaces properly. The second choice doesn't break any existing code.
There's a compromise: Change everything to a nice package structure, and provide a compatibility module for some transition period. Then everyone can adapt their code in a reasonable time. Ultimately the compatibility modules can disappear. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
participants (4)
-
David Ascher -
hinsen＠dirac.cnrs-orleans.fr -
Janko Hauser -
Paul F. Dubois