<br><br><div class="gmail_quote">On Wed, Feb 8, 2012 at 15:31, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2/8/2012 3:16 PM, Brett Cannon wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Feb 8, 2012 at 14:57, Terry Reedy <<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a><br></div><div class="im">
Would the following work? Treat a function as a 'loop' in that it<br>
may be executed repeatedly. Treat 'import x' in a function as what<br>
it is, an __import__ call plus a local assignment. Apply a version<br>
of the usual optimization: put a sys.modules-based lazy import<br>
outside of the function (at the top of the module?) and leave the<br>
local assignment "x = sys.modules['x']" in the function. Change<br>
sys.modules.__delattr__ to replace a module with a dummy, so the<br>
function will still work after a deletion, as it does now.<br>
<br>
Probably, but I would hate to force people to code in a specific way for<br>
it to work.<br>
</div></blockquote>
<br>
The intent of what I proposed it to be transparent for imports within functions. It would be a minor optimization if anything, but it would mean that there is a lazy mechanism in place.<br>
<br>
For top-level imports, unless *all* are made lazy, then there *must* be some indication in the code of whether to make it lazy or not.</blockquote><div><br></div><div>Not true; importlib would make it dead-simple to whitelist what modules to make lazy (e.g. your app code lazy but all stdlib stuff not, etc.).</div>
</div>