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 <rep...@bugs.python.org> <http://bugs.python.org/issue15295> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com