[Numpy-discussion] Lazy imports again

Travis Oliphant travis@continuum...
Mon Jul 16 22:37:31 CDT 2012


On Jul 16, 2012, at 4:50 PM, Ralf Gommers wrote:

> 
> 
> On Mon, Jul 16, 2012 at 6:28 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
> Hi All,
> 
> Working lazy imports would be useful to have. Ralf is opposed to the idea because it caused all sorts of problems on different platforms when it was tried in scipy.
> 
> Note that my being opposed is because the benefits are smaller than the cost. If there was a better reason than shaving a couple of extra ms off the import time or being able to more cleanly deprecate modules, then of course it's possible I'd change my mind.

This sort of cost / benefit analysis is always tricky.   The "benefits" are always subjective.  For some, shaving a few ms off of import times is *extremely* valuable and so they would opine that it absolutely outweights the "cost".  Others see such benefits as barely worth mentioning.   I doubt we can define an absolute scale that would allow such an optimization to actually be done.    

My personal view is that speeding up import times is an important goal (though not the *most* important goal).    The "costs" here are also very loosely defined.   Lazy imports were tried with SciPy.   Several people had problems with them.   Mostly it was difficult to not have a "brittle" implementation that didn't break someone downstream libraries concept of what "import" meant --- systems that try to "freeze" Python programs were particularly annoyed at SciPy's lazy import mechanism. 

However, I don't think that lazy imports should be universally eschewed.    They are probably not right for the NumPy library by default, but I think good use could be made of a system loaded before any other import by users who are looking to avoid the costs of importing all the packages imported by a library.  In particular, I suspect we could come up with an approach for C-API users like Andrew so that they could call _import_lazy() and then _import_array() and get what they want (hooks to the C-API) without what they don't (everything else on the Python side). 

I've implemented something like this in the past by using the metapath import hook to intercept import of a specific library.     It could be done for NumPy in a way that doesn't affect people who don't want it, but can be used by people who want to speed up their import times and don't need much from NumPy.

Certainly, in retrospect, it would have been a better design to allow the C-API to be loaded without everything else being loaded as well... -- maybe even providing a module *just* for importing the C-API that was in the top-level namespace "_numpy" or some such...    

Best, 

-Travis



> 
> Ralf
> 
>  
> I thought I'd open the topic for discussion so that folks who had various problems/solutions could offer input and the common experience could be collected in one place. Perhaps there is a solution that actually works.
> 
> Ideas?
> 
> Chuck
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120716/f4a6f2cd/attachment.html 


More information about the NumPy-Discussion mailing list