<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 10:00 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 1 August 2013 23:18, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>


>> I see 2 as the best one.  Is it really too late to change the return type<br>
>> of FileFinder.find_loader()? If we simply can't bear the backward<br>
>> compatibility risk (no matter how small <wink>),<br>
><br>
> We unfortunately can't. It would require a new method which as a stub would<br>
> call the old API to return the proper object (which is fine if you can come<br>
> up with a reasonable name).<br>
<br>
</div>Just musing on this one for a bit.<br>
<br>
1. We still have the silliness where we call "find_module" on metapath<br>
importers to ask them for a loader.<br>
2. We have defined an inflexible signature for find_loader on path<br>
entry finders (oops)<br>
3. There's other interesting metadata finders could expose *without*<br>
loading the module<br>
<br>
So, how does this sound: add a new API called "find_module_info" for<br>
both metapath importers and path entry finders (falling back to the<br>
legacy APIs). This would return a simple namespace potentially<br>
providing the following pieces of information, using the same rules as<br>
the corresponding loader does for setting the module attributes<br>
(<a href="http://docs.python.org/3/reference/import.html#loaders" target="_blank">http://docs.python.org/3/reference/import.html#loaders</a>):<br>
<br>
    __loader__<br>
    __name__<br>
    __package__<br>
    __path__<br>
    __file__<br>
    __cached__<br>
    __indirect__<br>
<br>
(We could also lose the double underscores for the namespace<br>
attributes, but I quite like the symmetry of keeping them)<br>
<br>
Thoughts?</blockquote><div><br></div><div>If you're going to do that, why stop at types.SimpleNamespace and not move all the way to a module object? Then you can simply start moving to APIs which take the module object to be operated on and the various methods in the loader, etc. and just fill in details as necessary; that's what I would do if I got to redesign the loader API today since it would simplify load_module() and almost everything would just become a static method which set the attribute on the module (e.g. ExecutionLoader.get_filename('some.module') would become ExecutionLoader.filename(module) or even ExecutionLoader.__file__(module) which gets really meta as you can then have a decorator which checks for a non-None value for that attribute on the module and then returns it as a short-circuit instead of calling the method). Only drawback I see is it not being easy to tell if a module has been initialized or not, but I don't view that as a critical issue. IOW introduce new_module()/fresh_module().</div>

<div><br></div><div>Even if types.SimpleNamespace is kept I do like the idea. Loaders could shift to working only off of the object and have their __init__ method standardized to take a single argument so what import is told about and what loaders work with is the same. Basically it becomes a caching mechanism of what finders can infer so that loaders can save themselves the hassle without complicated init call signatures.</div>

</div></div></div>