<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 4:28 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
Le Fri, 9 Aug 2013 00:34:34 -0600,<br>
Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> a écrit :<br>
<div class="im">> Abstract<br>
> ========<br>
><br>
> This PEP proposes to add a new class to ``importlib.machinery`` called<br>
> ``ModuleSpec``.  It will contain all the import-related information<br>
> about a module without needing to load the module first.  Finders will<br>
> now return a module's spec rather than a loader.  The import system<br>
> will use the spec to load the module.<br>
<br>
</div>Looks good on the principle.<br>
<div class="im"><br>
> Attributes:<br>
><br>
> * ``name`` - the module's name (compare to ``__name__``).<br>
> * ``loader`` - the loader to use during loading and for module data<br>
>   (compare to ``__loader__``).<br>
<br>
</div>Should it be the loader or just a factory to build it?<br>
I'm wondering if in some cases creating a loader is costly.<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> * ``package`` - the name of the module's parent (compare to<br>
>   ``__package__``).<br>
<br>
</div>Is it None if there is no parent?<br></blockquote><div><br></div><div>Top-level modules have the value of '' for __package__. None is used to represent an unknown value.</div><div><br></div><div>-Brett</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> * ``is_package`` - whether or not the module is a package.<br>
> * ``origin`` - the location from which the module originates.<br>
> * ``filename`` - like origin, but limited to a path-based location<br>
>   (compare to ``__file__``).<br>
<br>
</div>Can you explain the difference between origin and filename (or, better,<br>
give an example)?<br>
<div class="im"><br>
> * ``load(module=None, *, is_reload=False)`` - calls the loader's<br>
>   ``exec_module()``, falling back to ``load_module()`` if necessary.<br>
>   This method performs the former responsibilities of loaders for<br>
>   managing modules before actually loading and for cleaning up.  The<br>
>   reload case is facilitated by the ``module`` and ``is_reload``<br>
>   parameters.<br>
<br>
</div>So how about separate load() and reload() methods?<br>
<div class="im"><br>
> However, ``ModuleSpec.is_package`` (an attribute) conflicts with<br>
> ``InspectLoader.is_package()`` (a method).  Working around this<br>
> requires a more complicated solution but is not a large obstacle.<br>
<br>
</div>Or how about keeping the method API?<br>
<div class="im"><br>
> Module Objects<br>
> --------------<br>
><br>
> Module objects will now have a ``__spec__`` attribute to which the<br>
> module's spec will be bound.<br>
<br>
</div>Nice!<br>
<div class="im"><br>
> Loaders will have a new method, ``exec_module(module)``.  Its only job<br>
> is to "exec" the module and consequently populate the module's<br>
> namespace.  It is not responsible for creating or preparing the module<br>
> object, nor for any cleanup afterward.  It has no return value.<br>
<br>
</div>Does it work with extension modules as well? Generally, extension<br>
modules are populated when created (i.e. the two steps aren't separate<br>
at the C API level, IIRC).<br>
<br>
Regards<br>
<br>
Antoine.<br>
<br>
<br>
_______________________________________________<br>
Import-SIG mailing list<br>
<a href="mailto:Import-SIG@python.org">Import-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/import-sig" target="_blank">http://mail.python.org/mailman/listinfo/import-sig</a><br>
</blockquote></div><br></div></div>