[Numpy-discussion] Adding the new polynomial/chebyshev modules.

Robert Kern robert.kern@gmail....
Mon Nov 16 18:49:11 CST 2009


On Mon, Nov 16, 2009 at 18:39, Christopher Barker <Chris.Barker@noaa.gov> wrote:
> Robert Kern wrote:
>>> Is there a way to avoid importing everything when importing a module
>>> deep in a big package?
>>
>> The package authors need to keep the __init__.py files clear. There is
>> nothing you can do as a user.
>
> I figured. so, to bring this back on-topic:
>
> I recommend that no package imports anything it doesn't need to. It's
> just not that hard to import what you need.
>
> numpy appears to be pretty bad in this regard:
>
>  >>> len(sys.modules)
> 29
>  >>> import numpy
>  >>> len(sys.modules)
> 174

It's not *quite* as bad as that. There are a lot of keys in
sys.modules that point to None as an optimization (e.g. if foo/bar.py
imports math, let's say, the import system will look up foo.math,
which fails, so sys.modules['foo.math'] = None so it doesn't try that
again).

Here is the correct way to measure that:

>>> import sys
>>> old = set(sys.modules)
>>> len(old)
30
>>> import numpy
>>> new = set(sys.modules)
>>> from_numpy = [m for m in (new - old) if sys.modules[m] is not None]
>>> len(from_numpy)
93
>>> from_numpy
['numpy.lib._iotools', 'numpy.core.info', 'numpy.lib.getlimits',
'ctypes._endian', 'numpy.core.numerictypes', 'struct',
'numpy.random.info', 'numpy.linalg', 'numpy.testing',
'numpy.core.umath', 'numpy.core.scalarmath', 'string',
'numpy.lib.arraysetops', 'numpy.version', 'numpy.lib.type_check',
'numpy.lib._datasource', 'numpy.lib.io', 'numpy.ma.extras', 'token',
'numpy.fft.fftpack_lite', 'numpy.core.multiarray', 'dis', 'cStringIO',
'numpy.ma.core', 'numpy.add_newdocs', 'numpy.testing.decorators',
're', 'numpy.lib._compiled_base', 'numpy.random.mtrand', 'math',
'numpy.fft.helper', 'inspect', '_ctypes', 'numpy.lib.ufunclike',
'numpy.lib.info', 'ctypes', 'numpy.core._sort', 'numpy.core.memmap',
'traceback', 'itertools', 'numpy.fft.fftpack', 'opcode',
'numpy.linalg.lapack_lite', '__future__', '_sre', 'unittest',
'numpy.random', 'numpy.lib.twodim_base', 'operator', 'sre_constants',
'numpy.lib.arrayterator', 'numpy.lib.financial', 'imp',
'numpy.core.arrayprint', 'tokenize', 'numpy.lib.stride_tricks',
'numpy', 'numpy.core.defmatrix', 'cPickle', 'numpy.ma',
'numpy.testing.utils', 'gestalt', '_struct', 'numpy.core.fromnumeric',
'numpy.ctypeslib', 'numpy.lib.scimath', 'numpy.fft', 'numpy.lib',
'numpy.lib.function_base', 'sre_parse', 'sre_compile',
'numpy.lib.shape_base', 'numpy.lib.polynomial', 'numpy._import_tools',
'numpy.fft.info', 'numpy.core.records', 'numpy.core._dotblas',
'shutil', 'strop', 'numpy.testing.numpytest', 'numpy.core.numeric',
'numpy.linalg.info', 'numpy.core._internal', 'numpy.__config__',
'numpy.core', 'numpy.lib.index_tricks', 'numpy.lib.utils',
'numpy.core.defchararray', 'numpy.lib.format',
'numpy.testing.nosetester', 'time', 'numpy.lib.machar',
'numpy.linalg.linalg']

> with a simple "import numpy", I get all kinds of stuff I'm unlikely to
> need in every app, and if I do, I import it anyway:
>
> numpy.testing
> numpy.ma
> numpy.random
> numpy.linalg
> numpy.lib.financial
> numpy.lib.polynomial
> numpy.fft
>
>
> It's probably way too late from a backward compatibility perspective to
> change any of this, but I'd love to see that cleaned up.

Oh, good heavens, yes.

> Maybe we can clean up scipy, though?

Some of the parts checked in since 0.7, but otherwise not really, no.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


More information about the NumPy-Discussion mailing list