On Mon, Nov 16, 2009 at 18:39, Christopher Barker <chris.bar...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
