Message166939
> 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. |
|
Date |
User |
Action |
Args |
2012-07-31 00:28:04 | eric.snow | set | recipients:
+ eric.snow, barry, brett.cannon, georg.brandl, ncoghlan, larry, eric.araujo, skrah |
2012-07-31 00:28:04 | eric.snow | set | messageid: <1343694484.08.0.513510031013.issue15295@psf.upfronthosting.co.za> |
2012-07-31 00:28:03 | eric.snow | link | issue15295 messages |
2012-07-31 00:28:01 | eric.snow | create | |
|