On Tue, Feb 7, 2012 at 22:47, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy <tjre...@udel.edu> wrote: > > On 2/7/2012 9:35 PM, PJ Eby wrote: > >> 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. > > Yeah, this is one frequently reinvented wheel that could definitely do > with a standard implementation. Christian Heimes made an initial > attempt at such a thing years ago with PEP 369, but an importlib based > __import__ would let the implementation largely be pure Python (with > all the increase in power and flexibility that implies). > > 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. > I'm not sure such an addition would help much with the base > interpreter start up time though - most of the modules we bring in are > because we're actually using them for some reason. > It wouldn't. This would be for third-parties only. > > The other thing that shouldn't be underrated here is the value in > making the builtin import system PEP 302 compliant from a > *documentation* perspective. I've made occasional attempts at fully > documenting the import system over the years, and I always end up > giving up because the combination of the pre-PEP 302 builtin > mechanisms in import.c and the PEP 302 compliant mechanisms for things > like zipimport just degenerate into a mess of special cases that are > impossible to justify beyond "nobody got around to fixing this yet". > The fact that we have an undocumented PEP 302 based reimplementation > of imports squirrelled away in pkgutil to make pkgutil and runpy work > is sheer insanity (replacing *that* with importlib might actually be a > good first step towards full integration). > 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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com