[Import-SIG] PEP proposal: Per-Module Import Path

[Eric Snow]

On Sat, Aug 3, 2013 at 11:07 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 2 August 2013 13:34, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> I finally had a chance to look at your draft implementation. That's a
> neat attempt at backwards compatibility, but I'm not sure it will work
> properly - you already had to block out several interesting methods
> for compatibility reasons, and there's a potential for conflict even
> with the methods you did keep (since custom loaders may have
> additional methods beyond those in the specs).
>

Yeah, that was a pretty rough stab at it.  I've since done a little more,
including implementing __getattr__() and getting a little clever for
is_package.  And I'm still not sure it will work.  isinstance checks will
fail (duck-typing FTW) and id() gives a different value for the spec and
for the loader.  I suppose that's the rub with proxies.  So I'm not sure it
will work, but it *could* be close enough.  We'll see.


> YAFM is annoying (Yet Another Method, I'll let you fill in the rest),
> but I think it's better than trying to be too clever and accidentally
> breaking things.
>

That's my concern too.


>
> How about "find_import" as a new method name? And ImportSpec as the
> class name, rather than ModuleSpec?
>

To me "ImportSpec" says "spec for the import system".


> >> 4. We'd create a "SpecLoader" to offer backwards compatibility in the
> old
> >> __loader__ attribute.
> >
> > Interesting.  I had anticipated loaders still sticking around, still
> exposed
> > by module.__loader__ and filling most of their current role, especially
> with
> > regard to the optional PEP 302 APIs.  I suppose we could deprecate the
> > __loader__ attribute, and maybe even __package__, in favor of __spec__,
> but
> > I don't think there's any rush to do so before Python 4000.
>
> Yeah, I think having the spec as something people *don't* customise is
> a good idea.
>

I tried it both ways and it's a *lot* simpler if the spec is not designed
for modification.  I expect the case for modifying a spec would be pretty
uncommon.


>
> >> Slight(!) tangent from the original problem, but a worthwhile
> refactoring
> >> issue to tackle, I think :)
> >
> > Yeah, even if it proves too big a change for 3.4 and we take some other
> > approach for indirections, I think there's a lot to gain from separating
> the
> > module specification from the module and from the loader.  I've attached
> a
> > patch that does the bare minimum of what I think we'd want from
> ModuleSpec.
> > I'll probably flesh out more of my ideas for it later.
> >
> > Of course, I don't want anything here to get in the way of the .ref PEP
> > which I think has more concrete value.  So if this tangent threatens any
> > chance at getting indirection files for 3.4, I'd rather defer any effort
> on
> > these extras until 3.5 in favor of a simpler (if less desirable)
> approach.
>
> I just realised there's another added bonus to this approach:
> __spec__.__name__ will let us record the *real* name of modules
> executed via -m, even with __name__ set to "__main__". So it could
> also greatly simplify some aspects of PEP 395 :)
>

That's a good one.  I'll give it a try.

The patch I've got is pretty hefty.  Should I keep it low key and just post
it here, or would it be worth logging a ticket and posting it there for
review?  Once I'm comfortable with the patch I'll try sticking my .ref
patch on top and see how it looks.  I'll probably whip up a PEP for
ModuleSpec at that point if things are looking good.

I'm just worried about getting this done in time for 3.4.  On top of this
I'm really close on OrderedDict, ordered class definition namespace,
<class>.__definition_order__, and locals('__kworder__'), so I'm still kind
of nervous about taking on two non-trivial changes to the import system
with so little time before beta 1.  However, at this point I still think
it's doable. :)

-eric

p.s. I hadn't realized this list was "closed".  Should we change that, or
take this (both ModuleSpec and .ref) to python-ideas (or off-line)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20130807/d35ec3a9/attachment.html>