>>>>> "ej" == ej <eric> writes:
[snip]
ej> The current runtime overhead isn't so bad. Prabhu sent me a
ej> few numbers on the SciPy import (which contains maybe 10-15
ej> nested packages). I attached them below -- the overhead is
ej> less than 10%. It should be negligible for standard modules
ej> as only packages are really affected (right Prabhu?).
It depends on how you do it. If you have a sub-package that tries to
import a standard module it will go through all the parent packages
searching for the module and when it doesn't find one it will check in
sys.path. There are a few things to note:
(1) For a module in a package, the first import will be naturally
the slowest.
(2) Subsequent imports will be faster since failures are cached and
the package is already imported.
(3) If the module in question is not inside a package there will be
no slowdown whatsoever since there is no parent package at all.
I've timed this with vtk and it seems to be correct.
>>> import my_import, time # NOTE: I am not inside any package.
>>> s = time.time (); import vtkpython; print time.time()-s
1.06130003929
>>> import time
>>> s = time.time (); import vtkpython; print time.time()-s
1.06413698196
Its slower with standard import you may say - but that might just be
my kernel's scheduling affecting things. I think its fair to conclude
that there is no slowdown if you are not inside a package and based on
my earlier timings, that recursive searching thru package parents is
not too expensive either.
There is one issue. lets say we have two sub-packages that have
modules of the same name. Then if we explicitly want the other
sub-packages module to be imported there is currently no way of doing
it. In such a case maybe adding a __parent__ or using (__ as ni did)
might be a good idea too.
prabhu
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4