[Python-Dev] Getting importlib into the standard library for 3.1 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Jan 8 22:21:06 CET 2009

Brett Cannon wrote:

On Thu, Jan 8, 2009 at 12:35, Nick Coghlan <ncoghlan at gmail.com> wrote:

Brett Cannon wrote:

One, does anyone have issues if I check in importlib? We have typically said code has to have been selected as best-of-breed by the community first, so I realize I am asking for a waiver on this one. That rule has never really applied to things that are part of the interpreter itself though (how could it?). Well, it's not part of the interpreter yet. That can be viewed as a separate step.

True, but what you're doing here can be viewed as the continuation of the original implementation plan for PEP 302 - it was always intended that every module would eventually get a loader attribute, and that's one of the things an import system based on your importlib would provide.

My main question would be how it relates to the existing import machinery emulation in pkgutil. If adding importlib lets us largely drop that emulation (instead replacing it with invocations of importlib), then that seems like a big win to me. You mean stuff like pkgutil.ImpImporter? importlib will be fully modular with metapath importers for everything short of sys.modules (and even that could be done if people care, but I would rather keep sys.modules stuff on the fast path). So there will be a metapath importer that handles sys.path/sys.pathhooks/sys.pathimportercache. That work is part of the "importlib is semantically done, but there are some things I want to imrpove" todo list. If you are more talking about something else I am not sure what you are after. Every module will have a proper loader with importlib.

I'm talking about the fact that imp.get_loader doesn't exist, hence the existence of pkgutil.get_loader and its supporting machinery.

My question is whether or not it is possible to replace the current emulation code in pkgutil with appropriate imports from importlib and thus get rid of the current semantic differences that exist between the real import machinery and the pkgutil emulation (mainly in the area of non-PEP 302 module loaders, such as the special case for the Windows directory information).

Upgrading the pkgutil interface to match the actual semantics of the import system instead of only approximating them would be a decent win in its own right, even if there turn out to be other issues that keep us from switching to importlib as the sole import mechanism.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list