Re: PEP 451: Big update.

Hi Antoine,

Thanks for the feedback.  Comments inline.

On Thu, Sep 19, 2013 at 4:22 AM, Antoine Pitrou <[email protected]> wrote:

> > origin - a string for the location from which the module is loaded,
> > e.g. "builtin" for built-in modules and the filename for modules
> > loaded from source.
>
> Filename or filepath? What if the module is stored in e.g. a ZIP file?
>

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.


>
> > submodule_search_locations - list of strings for where to find
> > submodules, if a package (None otherwise).
>
> Why isn't is_package exposed as an attribute too?
>

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.


> > cached (property) - a string for where the compiled module will be
> > stored
>
> "where" is a filesystem location?
> (absolute? relative to the origin?)
>

As Brett noted (and the module attribute table further on indicates), this
is the same as the __cache__ attribute of modules.


> > has_location (RO-property) - the module's origin refers to a location.
>
> filesystem location? What about ZIP files?
>

Also as Brett indicated, this is a flag that indicates that "origin" should
be copied into __file__
on corresponding module objects.  However, the summary is pretty unclear.
 I'll fix that.


>
> > spec_from_file_location(name, location, *, loader=None,
> > submodule_search_locations=None) - factory for file-based module specs
>
> What does it mean? Is it able to make "intelligent" decisions depending
> on e.g. whether the module is an extension module or a pure Python
> module?
>

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.


>
> > from_loader(name, loader, *, origin=None, is_package=None) - factory
> > based on information provided by loaders.
>
> That description is rather unhelpful.
>

Likewise I'll add more explanation for this as well as improve the summary.


> > importlib.find_spec(name, path=None) will return the spec for a module.
>
> Is the module supposed to be already loaded or not? How is the spec
> "found"?
>

This function is the replacement for importlib.find_loader().  Instead of
returning a loader it
returns a spec.  Otherwise it's the same.  I'll make the summary more clear.

-eric

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