[Import-SIG] Rough PEP: A ModuleSpec Type for the Import System

[Antoine Pitrou]

Hi,

Le Fri, 9 Aug 2013 00:34:34 -0600,
Eric Snow <ericsnowcurrently at gmail.com> a écrit :
> Abstract
> ========
> 
> This PEP proposes to add a new class to ``importlib.machinery`` called
> ``ModuleSpec``.  It will contain all the import-related information
> about a module without needing to load the module first.  Finders will
> now return a module's spec rather than a loader.  The import system
> will use the spec to load the module.

Looks good on the principle.

> Attributes:
> 
> * ``name`` - the module's name (compare to ``__name__``).
> * ``loader`` - the loader to use during loading and for module data
>   (compare to ``__loader__``).

Should it be the loader or just a factory to build it?
I'm wondering if in some cases creating a loader is costly.

> * ``package`` - the name of the module's parent (compare to
>   ``__package__``).

Is it None if there is no parent?

> * ``is_package`` - whether or not the module is a package.
> * ``origin`` - the location from which the module originates.
> * ``filename`` - like origin, but limited to a path-based location
>   (compare to ``__file__``).

Can you explain the difference between origin and filename (or, better,
give an example)?

> * ``load(module=None, *, is_reload=False)`` - calls the loader's
>   ``exec_module()``, falling back to ``load_module()`` if necessary.
>   This method performs the former responsibilities of loaders for
>   managing modules before actually loading and for cleaning up.  The
>   reload case is facilitated by the ``module`` and ``is_reload``
>   parameters.

So how about separate load() and reload() methods?

> However, ``ModuleSpec.is_package`` (an attribute) conflicts with
> ``InspectLoader.is_package()`` (a method).  Working around this
> requires a more complicated solution but is not a large obstacle.

Or how about keeping the method API?

> Module Objects
> --------------
> 
> Module objects will now have a ``__spec__`` attribute to which the
> module's spec will be bound.

Nice!

> Loaders will have a new method, ``exec_module(module)``.  Its only job
> is to "exec" the module and consequently populate the module's
> namespace.  It is not responsible for creating or preparing the module
> object, nor for any cleanup afterward.  It has no return value.

Does it work with extension modules as well? Generally, extension
modules are populated when created (i.e. the two steps aren't separate
at the C API level, IIRC).

Regards

Antoine.