<p dir="ltr"><br>
On 20 Sep 2013 00:12, "Brett Cannon" <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Thu, Sep 19, 2013 at 6:22 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
>><br>
>><br>
>> Hi,<br>
>><br>
>> I have some questions and comments:<br>
>><br>
>> > 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>
>> Filename or filepath? What if the module is stored in e.g. a ZIP file?<br>
><br>
><br>
> I think this would be what __file__ would be set to for zipfiles, so for zip files it would be e.g. /some/file.zip/path/to/module.py<br>
>  <br>
>><br>
>><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>
><br>
><br>
> It's redundant. The test for whether something is a package is literally ``submodule_search_locations is not None``. It just doesn't isn't complicated enough to warrant another attribute. Plus being a package isn't as important per-se as a concept as much as having a search path.<br>

>  <br>
>><br>
>><br>
>> > cached (property) - a string for where the compiled module will be<br>
>> > stored<br>
>><br>
>> "where" is a filesystem location?<br>
>> (absolute? relative to the origin?)<br>
><br>
><br>
> It's what <a href="http://docs.python.org/3/library/imp.html#imp.cache_from_source">http://docs.python.org/3/library/imp.html#imp.cache_from_source</a> would return.<br>
>  <br>
>><br>
>><br>
>> > has_location (RO-property) - the module's origin refers to a location.<br>
>><br>
>> filesystem location? What about ZIP files?<br>
><br>
><br>
> It's a flag to basically say that origin contains what __file__ should be.</p>
<p dir="ltr">Thus indicating that get_data() on the loader can be used sensibly. Perhaps we could just make setting __file__ conditional on the loader defining get_data, rather than having it be a spec attribute?</p>
<p dir="ltr">I also suggest that we adopt the convention of using angle brackets in non-location origins. So names like "<builtin>" and "<frozen>".</p>
<p dir="ltr">To respond to something Paul said, our completely opaque token is "loader_state", origin is still intended to be a human readable string.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> -Brett<br>
>  <br>
>><br>
>><br>
>> > spec_from_file_location(name, location, *, loader=None,<br>
>> > submodule_search_locations=None) - factory for file-based module specs<br>
>><br>
>> 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>
>><br>
>> > from_loader(name, loader, *, origin=None, is_package=None) - factory<br>
>> > based on information provided by loaders.<br>
>><br>
>> That description is rather unhelpful.<br>
>><br>
>> > importlib.find_spec(name, path=None) will return the spec for a module.<br>
>><br>
>> Is the module supposed to be already loaded or not? How is the spec<br>
>> "found"?<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="https://mail.python.org/mailman/listinfo/import-sig">https://mail.python.org/mailman/listinfo/import-sig</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Import-SIG mailing list<br>
> <a href="mailto:Import-SIG@python.org">Import-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/import-sig">https://mail.python.org/mailman/listinfo/import-sig</a><br>
><br>
</p>