[Numpy-discussion] package vs module

Tim Hochberg tim.hochberg at ieee.org
Tue Jan 7 09:35:17 EST 2003


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










More information about the NumPy-Discussion mailing list