From: Tim H. <tim...@ie...> - 2003-01-07 17:34:52
|
Pearu Peterson wrote: >On Mon, 6 Jan 2003, Perry Greenfield wrote: > > > >>The main disadvantages I see so far are: >> >>1) One will either have to change import statements in old code >> to match the new style (a pain, but generally changing imports >> is not terribly difficult since they are easy to identify) or >> explicitly add the path to each 3rd party module to Python >> Path (or some equivalent). >>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 >> require having people install FFT in the Standard Library >> directory structure after Python is installed. Rather, we would >> probably have numarray look for extension modules in a standard >> named site-packages directory (or site-numarray?) or otherwise >> check a numarraypath environmental variable so that >> import numarray.FFT works properly. Perhaps others have ideas >> about how to best handle this. >> >>Any other issues being overlooked? >> >> > >There is one, though not so critical at this point but I will raise >it anyway. In summary, I am +1 for making numarray a package. > >The issue is releated to import time and memory usage: more extension >modules in a package increase both of them, even if users have no >indention to use these modules. On slower machines this may cause >inconvinieces, especially in applications that call Python multiple times >for short tasks containing numarray operation. > > That's not right, is it? I'm pretty certain that submodules in a package are not loaded until explicitly imported. I'm not sure why SciPy is slow, maybe the __init__ imports everything? I don't have a copy here so I can't check right now. In any event I'm +1 for putting it in a package unless it interferes with it getting into the core. As Paul mentioned keeping it in a zip archive would be even cooler once that's an option. -tim |