<div dir="ltr"><div>Hi Antoine,</div><div><br></div><div>Thanks for the feedback. Comments inline.</div><div><br></div>On Thu, Sep 19, 2013 at 4:22 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> origin - a string for the location from which the module is loaded,<br>
> e.g. "builtin" for built-in modules and the filename for modules<br>
> loaded from source.<br>
<br>
</div>Filename or filepath? What if the module is stored in e.g. a ZIP file?<br></blockquote><div><br></div><div>As Brett mentioned, it would be whatever is currently bound to __file__. Keep in mind that the two things I listed are just examples of the sorts of things that would go into "origin". The point of "origin" is actually explained in more detail further on in the PEP.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> submodule_search_locations - list of strings for where to find<br>
> submodules, if a package (None otherwise).<br>
<br>
Why isn't is_package exposed as an attribute too?<br></blockquote><div><br></div><div>We had some discussion on this on a previous revision of the PEP. Initially I had is_package as a property of ModuleSpec. However, we came to the agreement that whether or not the spec represents a package is not very important once you have the spec. This contrasts with the is_package parameter to ModuleSpec which is useful since it represents a set of things that should be effected on the new spec object. Ultimately Nick put it best when he said that we need to de-emphasize the superficial package/module distinction, not enshrine it as an attribute. The PEP actually addresses the question of is_package in the "Omitted Attributes and Methods" section.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> cached (property) - a string for where the compiled module will be<br>
> stored<br>
<br>
</div>"where" is a filesystem location?<br>
(absolute? relative to the origin?)<br></blockquote><div><br></div><div>As Brett noted (and the module attribute table further on indicates), this is the same as the __cache__ attribute of modules.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> has_location (RO-property) - the module's origin refers to a location.<br>
<br>
</div>filesystem location? What about ZIP files?<br></blockquote><div><br></div><div>Also as Brett indicated, this is a flag that indicates that "origin" should be copied into __file__</div><div>on corresponding module objects. However, the summary is pretty unclear. I'll fix that.</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>
> spec_from_file_location(name, location, *, loader=None,<br>
> submodule_search_locations=None) - factory for file-based module specs<br>
<br>
</div>What does it mean? Is it able to make "intelligent" decisions depending<br>
on e.g. whether the module is an extension module or a pure Python<br>
module?<br></blockquote><div><br></div><div>It does make some intelligent decisions. Otherwise a finder would just call ModuleSpec directly. (All three factory functions are there for the convenience of finders.) I'll add some explanation on what those decisions entail and also clarify the summary.</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>
> from_loader(name, loader, *, origin=None, is_package=None) - factory<br>
> based on information provided by loaders.<br>
<br>
</div>That description is rather unhelpful.<br></blockquote><div><br></div><div>Likewise I'll add more explanation for this as well as improve the summary.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> importlib.find_spec(name, path=None) will return the spec for a module.<br>
<br>
</div>Is the module supposed to be already loaded or not? How is the spec<br>
"found"?<br></blockquote><div></div></div><br></div><div class="gmail_extra">This function is the replacement for importlib.find_loader(). Instead of returning a loader it</div><div class="gmail_extra">returns a spec. Otherwise it's the same. I'll make the summary more clear.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-eric</div></div>