[Import-SIG] PEP 451: Big update.

[Eric Snow]

On Thu, Sep 19, 2013 at 5:28 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 19 September 2013 11:22, Antoine Pitrou <solipsis at pitrou.net> 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?
>
> I haven't been following this thread closely, but this is a good
> point. There is a general issue that for modules loaded off sys.path,
> the module "location" needs to be somehow jammed into a string form
> (the absolute path for files, zip/file/path.zip/location/in/zipfile
> for zipfiles, but potentially anything at all for custom loaders) and
> for things loaded off sys.meta_path there's no need for any concept of
> path at all (that's how builtins, frozen modules et al work).
>
> It's worth being clear on both how this origin should be constructed
> in the general case (for the guidance of people implementing
> non-standard importers) and what users of the data can assume when
> using the data (can they split the value on os.sep or '/', for
> example, or is it in effect an opaque token).
>

Actually, "origin" is meant to be pretty unconstrained string.  It only has
2 explicit purposes: use in spec.module_repr() and as the value of __file__
when spec.has_location is true.  The loader may use "origin" however it
likes.  Presumably the finder would populate origin in whatever format the
loader needs (if the loader even needs "origin"), but that's between the
finder and loader.  If the loader needs even more info, the finder can just
stick it into the spec's loader_state attribute.


>
> Some of the blame for all this being vague at the moment is down to me
> - when we were writing PEP 302, I wasn't brave enough to claim that
> path entries could be opaque token values, but I didn't want to insist
> that all importers had to follow a specific structure. So I ignored
> the issue and we just ended up with normal paths, and zipfiles which
> treat the zipfile as a pseudo-directory. And no examples of corner
> cases to keep people honest. My apologies for that...
>

As Nick pointed out, the "loader_state" attribute of ModuleSpec objects is
 meant to be the container for any extra data the loader needs.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20130919/d9bbf94f/attachment-0001.html>