On Wed, Jul 2, 2008 at 21:38, David Cournapeau <cournapeau@cslab.kecl.ntt.co.jp> wrote:
On Wed, 2008-07-02 at 21:21 -0500, Robert Kern wrote:
On Wed, Jul 2, 2008 at 20:23, David Cournapeau <cournapeau@cslab.kecl.ntt.co.jp> wrote:
I think that import numpy.core being slower than import numpy is a bug which can be solved without breaking anything, though.
It does not appear to be slower to me.
It isn't either on my computer.
So ... what were you referring to?
While we are talking about import timings, there was a system for lazy import at some point, right (this is when I first tried python and numpy a few years ago, so I may mix with something else) ?
There is special purpose code, yes. We used to use it to load proxy objects for scipy subpackages such that "import scipy" would have scipy.stats semi-immediately available. We have stopped using it because of fragility, confusing behavior at the interpreter, py2exe problems, and my general abhorrence of things which mess too deeply with imports. It is not a general-purpose solution for lazily-loading stdlib modules, I don't think.
Because we could win between 20 and 40 % time of import by lazily importing a few modules (namely urllib, which I guess it not often used, and already takes around 20-30 ms; inspect and compiler are takinh a long time too, but maybe those are always needed, I have not checked carefully). Maybe this would be complicated to implement for numpy, though.
These imports could easily be pushed down into the handful of functions that need them (with an appropriate comment about why they are down there). There is no need to have complicated machinery involved. Do you have a breakdown of the import costs? -- 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