On 2/7/2012 9:35 PM, PJ Eby wrote:
> On Tue, Feb 7, 2012 at 6:40 PM, Terry Reedy <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>> wrote:
>
> importlib could provide a parameterized decorator for functions that
> are the only consumers of an import. It could operate much like this:
>
> def imps(mod):
> def makewrap(f):
> def wrapped(*args, **kwds):
> print('first/only call to wrapper')
> g = globals()
> g[mod] = __import__(mod)
> g[f.__name__] = f
> f(*args, **kwds)
> wrapped.__name__ = f.__name__
> return wrapped
> return makewrap
>
> @imps('itertools')
> def ic():
> print(itertools.count)
>
> ic()
> ic()
> #
> first/only call to wrapper
> <class 'itertools.count'>
> <class 'itertools.count'>
>
>
> If I were going to rewrite code, I'd just use lazy imports (see
> http://pypi.python.org/pypi/Importing ). They're even faster than this
> approach (or using plain import statements), as they have zero per-call
> function call overhead.
My code above and Importing, as I understand it, both delay imports
until needed by using a dummy object that gets replaced at first access.
(Now that I am reminded, sys.modules is the better place for the dummy
objects. I just wanted to show that there is a simple solution (though
more specialized) even for existing code.) The cost of delay, which
might mean never, is a bit of one-time extra overhead. Both have no
extra overhead after the first call. Unless delayed importing is made
standard, both require a bit of extra code somewhere.
> It's just that not everything I write can depend on Importing.
> Throw an equivalent into the stdlib, though, and I guess I wouldn't have
> to worry about dependencies...
And that is what I think (agree?) should be done to counteract the
likely slowdown from using importlib.
> (To be clearer; I'm talking about the
> http://peak.telecommunity.com/DevCenter/Importing#lazy-imports feature,
> which sticks a dummy module subclass instance into sys.modules, whose
> __gettattribute__ does a reload() of the module, forcing the normal
> import process to run, after first changing the dummy object's type to
> something that doesn't have the __getattribute__ any more. This ensures
> that all accesses after the first one are at normal module attribute
> access speed. That, and the "whenImported" decorator from Importing
> would probably be of general stdlib usefulness too.)
--
Terry Jan Reedy
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