[Import-SIG] Rough PEP: A ModuleSpec Type for the Import System
Brett Cannon
brett at python.org
Fri Aug 9 16:43:10 CEST 2013
On Fri, Aug 9, 2013 at 4:28 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> 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.
>
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
> Import-SIG at python.org
> http://mail.python.org/mailman/listinfo/import-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20130809/3465489b/attachment.html>
More information about the Import-SIG
mailing list