<p dir="ltr"><br>
On Aug 1, 2013 8:36 AM, "Brett Cannon" <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> 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().<br>

><br>
> 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.</p>

<p dir="ltr">This is pretty much exactly what I've been thinking about since PyCon.  The only difference is that I have a distinct ModuleSpec class and modules would get a new __spec__ attribute.</p>
<p dir="ltr">-eric</p>