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

[Brett Cannon]

On Thu, Jan 8, 2009 at 13:21, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.
>

True. I am just trying to be diplomatic and not force importlib down
anyone's throats. =)

>>> 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.
>

Ah, OK.

> 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).
>

Looking at pkgutil.get_loader it would not be hard to expose the same
thing in importlib. Since one of the motivating factors in this is to
redo the import machinery from a PEP 302 standpoint the need for
pkgutil should quickly go or easily shift to importlib as needed. It's
just a matter of exposing an API.

-Brett