[Numpy-discussion] "import numpy" is slow
Stéfan van der Walt
Thu Jul 31 04:42:02 CDT 2008
2008/7/31 Andrew Dalke <email@example.com>:
>> Numpy has a very flat namespace, for better or worse, which implies
>> many imports.
> I don't get the feeling that numpy is flat. Python's stdlib is flat.
> Numpy has many 2- and 3-level modules.
With 500+ functions in the root namespace, I'd call numpy flat.
> If I had my way, remove things like (in numpy/__init__.py)
> import linalg
> import fft
> import random
> import ctypeslib
> import ma
> but leave the list of submodules in "__all__" so that "from numpy
> import *" works. Perhaps add a top-level function to 'import_all()'
> which mimics the current behavior, and have iPython know about it so
> interactive users get it automatically. Or something like that.
> Yes, I know the numpy team won't change this behavior. I want to
> know why you all will consider changing.
Maybe when we're convinced that there is a lot to be gained from
making such a change. From my perspective, it doesn't look good:
I) Major code breakage
II) Confused users
III) More difficult function discovery for beginners
I) Slight improvement in startup speed.
>>> Getting rid of these functions, and thus getting rid of the import
>>> speeds numpy startup time by 3.5%.
>> While I appreciate you taking the time to find these niggles, but we
>> are short on developer time as it is. Asking them to spend their
>> precious time on making a 3.5% improvement in startup time does not
>> make much sense. If you provide a patch, on the other hand, it would
>> only take a matter of seconds to decide whether to apply or not.
>> You've already done most of the sleuth work.
> I wrote that I don't know the reasons for why the design was as it
> is. Are those functions ("english_upper", "english_lower",
> "english_capitalize") expected as part of the public interface for
> the module? The lack of a "_" prefix and their verbose docstrings
> implies that they are for general use. In that case, they can't
> easily be gotten rid of. Yet it doesn't make sense for them to be
> part of 'numerictypes'.
Anything underneath numpy.core that is not exposed as numpy.something
is not for public consumption.
More information about the Numpy-discussion