This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients barry, brett.cannon, eric.araujo, eric.snow, georg.brandl, larry, ncoghlan, skrah
Date 2012-07-31.00:28:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1343694484.08.0.513510031013.issue15295@psf.upfronthosting.co.za>
In-reply-to
Content
> I certainly struggled with this term.  I almost picked PathFinder (or "path
> finder") since that's the name of the actual class used in the implementation,
> but then I thought this might be too implementation specific.

Considering that the goal is for importlib to be the common import machinery for the various Python implementations, this might not be inappropriate.

> You ask in [2] whether "path importer" refers specifically to the callables on
> sys.path_hooks.  Can you site a reference for this?  I found one reference in
> PEP 302 to "path importer" but it's hard to tell exactly what that is
> referring to.

Unfortunately not.  There aren't many people that use import hook terminology and I already have a terrible memory. :)  Regardless, I find "path importer" a little too ambiguous.

>>* (glossary.rst) sys path finder: having "sys" is a nice touch, making it more distinct and more explicit.
>
> TBH, I'm not crazy about the term "sys path finder" either but I couldn't
> think of anything better.

What don't you like about the "sys path thingee" names?  I find them to be nice and explicit.  I'll mull this over some more.

> In a subsequent comment, Nick suggests this whole chapter be called the
> "Import System" instead of the "Import Machinery", but I've been thinking
> "Import Protocol" might be good too.

I agree with Nick.

> The background at
> the top of the chapter is really just there to set the stage (and because
> afaict, nothing like that existed before :).

And it does a good job of it.

>>* (importlib.rst) SourceFileLoader.load_module(): What about when the name
>>* does not match?
>
> An ImportError gets raised?  Were you suggesting that some additional
> documentation should be added for this?

I guess I was just noting a possible hole in the Import System (sounds nice, doesn't it <wink>) specification.  Since importlib is a complete reference implementation, it's not critical to have every detail spelled out (at least, that's seems to be the status quo).

>>* (import_machinery.rst) how about a section devoted just to the attributes
>>* of modules and packages, perhaps expanding upon or supplanting the related
>>* entries in the data model reference page?
>
> I've added an XXX for this.  I think the right thing to do is to update the
> data model chapter, and add a link from here to there.

Perfect.

>>* (import_machinery.rst) Meta path loaders, end of paragraph 2: "The finder
>>* could also be a classmethod that returns an instance of the class."
>
> I don't understand what you're suggesting here.

Yeah, that was poorly worded.  I'd meant to suggest that you could document the alternative to find_module() and load_module() being regular methods of the same object.  For instance:

class MyMetaHook:
    @classmethod
    def find_module(cls, name, path=None):
        return cls()
    def load_module(self, name):
        raise ImportError("You lose!")

Thus, the "finder" is the class, and the "loader" is the instance.

>>* (import_machinery.rst) Meta path loaders: "If the load fails, the loader
>>* needs to remove any modules..." is a pretty exceptional case, since the
>>* modules is not in charge of its parent or children, nor of import
>>* statements executed for it.  Is this a new requirement?
>
> I don't think so.  I lifted it from somewhere (hard to remember exactly where
> now ;).  PEP 302?

Nick made the point more clearly.  :)

>>* (simple_stmts.rst) the from list can include submodules which must be
>>* imported separately, implying a step 1b
>
> I couldn't figure out what to say differently here.

No, you've got it covered.
History
Date User Action Args
2012-07-31 00:28:04eric.snowsetrecipients: + eric.snow, barry, brett.cannon, georg.brandl, ncoghlan, larry, eric.araujo, skrah
2012-07-31 00:28:04eric.snowsetmessageid: <1343694484.08.0.513510031013.issue15295@psf.upfronthosting.co.za>
2012-07-31 00:28:03eric.snowlinkissue15295 messages
2012-07-31 00:28:01eric.snowcreate