<br><br><div class="gmail_quote">On Tue, Feb 7, 2012 at 22:47, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</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 Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> wrote:<br>
> On 2/7/2012 9:35 PM, PJ Eby wrote:<br>
</div><div class="im">>> It's just that not everything I write can depend on Importing.<br>
>> Throw an equivalent into the stdlib, though, and I guess I wouldn't have<br>
>> to worry about dependencies...<br>
><br>
> And that is what I think (agree?) should be done to counteract the likely<br>
> slowdown from using importlib.<br>
<br>
</div>Yeah, this is one frequently reinvented wheel that could definitely do<br>
with a standard implementation. Christian Heimes made an initial<br>
attempt at such a thing years ago with PEP 369, but an importlib based<br>
__import__ would let the implementation largely be pure Python (with<br>
all the increase in power and flexibility that implies).<br>
<br></blockquote><div><br></div><div>I'll see if I can come up with a pure Python way to handle setting attributes on the module since that is the one case that my importers project code can't handle.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not sure such an addition would help much with the base<br>
interpreter start up time though - most of the modules we bring in are<br>
because we're actually using them for some reason.<br></blockquote><div><br></div><div>It wouldn't. This would be for third-parties only.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The other thing that shouldn't be underrated here is the value in<br>
making the builtin import system PEP 302 compliant from a<br>
*documentation* perspective. I've made occasional attempts at fully<br>
documenting the import system over the years, and I always end up<br>
giving up because the combination of the pre-PEP 302 builtin<br>
mechanisms in import.c and the PEP 302 compliant mechanisms for things<br>
like zipimport just degenerate into a mess of special cases that are<br>
impossible to justify beyond "nobody got around to fixing this yet".<br>
The fact that we have an undocumented PEP 302 based reimplementation<br>
of imports squirrelled away in pkgutil to make pkgutil and runpy work<br>
is sheer insanity (replacing *that* with importlib might actually be a<br>
good first step towards full integration).<br></blockquote><div><br></div><div>I actually have never bothered to explain import as it is currently implemented in any of my PyCon import talks precisely because it is such a mess. It's just easier to explain from a PEP 302 perspective since you can actually comprehend that. </div>
</div>