Re: PEP proposal: Per-Module Import Path

On Wed, Aug 7, 2013 at 9:08 PM, Eric Snow <[email protected]>wrote:

>
>
>
> On Sat, Aug 3, 2013 at 11:07 PM, Nick Coghlan <[email protected]> wrote:
>
>> On 2 August 2013 13:34, Eric Snow <[email protected]> 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 it's all written up in a PEP you can post an issue for the code.


>  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. :)
>

I personally view all of this as bonus stuff that is in no way required to
make Python function or make some new class of solution available, so I
wouldn't stress about getting in for 3.4.


>
> -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)?
>

Eric or Barry are the admins so they can change the wording. I say just
leave it here for now until people are happy with the proposal and then it
can be kicked up to python-dev (python-ideas isn't needed in this case
since we have this mailing list specifically for import discussions).

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