[Python-Dev] Write All New Import Hooks (PEP 302) in Python, Not C

[Samuele Pedroni]

From: "Just van Rossum" <just@letterror.com>
>
> The sys.meta_path feature adds 32 lines to import.c, it's *really*
> useful and easy to use. I would be *extremely* sad to see it go.
>
> (I had an immediate use for it in test_importhooks.py: after a test is
> run I wanted to unload the modules that were imported during the test.
> The ImportTracker is a meta importer and only *records* imports.  ...

I agree with Guido that special cookies can be used for normal importers.

I see also the point for such really _meta_ importers. But if one has many of
them how the code that installs them respectively the user decide on the order
of invocation.

It seems that theoretically to let code programatically alter meta_path,
there's a need for categories/priorities for meta importers:

- loggging importers come before everything
- global importers after
etc

Lacking this, it seems equivalent to installing __import__ hooks apart a tiny
bit of convenience.

> There should be only one way to do it if import.c did it only one way.
> Overriding or emulating builtin and frozen imports *must* be possible,
> and sys.meta_path is the feature for it. A key aspect of sys.meta_path
> is that it allows to refactor import.c in a really nice way; in the
> future, sys.meta_path would look like this:
>
>     [BuiltinImporter, FrozenImporter, PathImporter]
>
> sys.meta_path is then the central import dispatcher. PathImporter would
> be responsible for sys.path/pkg.__path__ handling and invoking
> sys.path_hooks and dealing with sys.path_import_cache. It is *key* to
> PEP 302, and to me simply a killer feature.

This would be nice, but if the above point is not resolved and this is not
concretely implemented, we risk to have meta_path used in non-intended ways or
be as much problematic as __import__.

Lacking precise policies and clear-cut commitment for its future uses, it's
better left out (it can be added in the future).