Eric Snow added the comment:
> 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.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue15295>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
