numarray repackaging, last call...
Based on the comments I have received, the numarray repackaging is shaping up as shown below: Here are the planned renamings for the numarray modules as we transition to a package: numarray --> numarray.numeric recarray --> numarray.records chararray --> numarray.strings ndarray --> numarray.generic * --> numarray.* Note that class and function names will remain unchanged, so recarray.RecArray will become numarray.records.RecArray. Here are the renamings for the current and planned add-on packages consolidated into a single add-ons distribution: LinearAlgrebra2 --> numarray.linear_algebra FFT2 --> numarray.fft RandomArray2 --> numarray.random_array Convolve --> numarray.convolve Convolve.Image --> numarray.image MA2 --> numarray.ma Future 3rd party packages that require numarray specific C extensions should locate themselves directly in the numarray package. Doing so makes it easy to figure out what to delete when extensions need to be rebuilt. If you don't want to, that's OK too. Barring a sudden burst of interest or superior name choice, I think the top level package name should just remain "numarray". Stub modules will be included in the first few repackaged releases to make it possible to import the primary modules (numarray, recarray, chararray, and ndarray) as you do with numarray-0.5. This will relax the requirement for synchronous change of numarray and software which uses numarray. The stub modules will be activated either through the creation of a .pth file or via additions to PYTHONPATH to make them visible. This is a backwards compatability mode only, not recommended usage following the repackaging. Thanks to everyone who responded. Final comments? -- Todd Miller jmiller@stsci.edu STSCI / ESS / SSB
participants (1)
-
Todd Miller