[Numpy-discussion] "import numpy" is slow

[Stéfan van der Walt]

2008/7/31 Andrew Dalke <dalke@dalkescientific.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

vs.

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.

Stéfan