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

Robert Kern robert.kern at gmail.com
Mon Nov 16 19:49:11 EST 2009

On Mon, Nov 16, 2009 at 18:39, Christopher Barker <Chris.Barker at 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

Here is the correct way to measure that:

>>> import sys
>>> old = set(sys.modules)
>>> len(old)
>>> import numpy
>>> new = set(sys.modules)
>>> from_numpy = [m for m in (new - old) if sys.modules[m] is not None]
>>> len(from_numpy)
>>> 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',

> 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