[Python-Dev] Getting importlib into the standard library for 3.1

[Nick Coghlan]

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 meta_path 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 meta_path
> importer that handles sys.path/sys.path_hooks/sys.path_importer_cache.
> 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
---------------------------------------------------------------