Re: Rough PEP: A ModuleSpec Type for the Import System

On Fri, Aug 9, 2013 at 4:28 AM, Antoine Pitrou <[email protected]> wrote:

>
> Hi,
>
> Le Fri, 9 Aug 2013 00:34:34 -0600,
> Eric Snow <[email protected]> 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.
>

Theoretically it could be costly, but up to this point I have not seen a
single loader that cost a lot to create. Every loader I have ever written
just stores details that the finder had to calculate for it's work and
potentially stores something, e.g. an open zipfile that the finder used to
see if a module was there.


>
> > * ``package`` - the name of the module's parent (compare to
> >   ``__package__``).
>
> Is it None if there is no parent?
>

Top-level modules have the value of '' for __package__. None is used to
represent an unknown value.

-Brett



>
> > * ``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.
>
>
> _______________________________________________
> Import-SIG mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/import-sig
>

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig