<p dir="ltr">On Sep 25, 2013 7:05 AM, "Brett Cannon" <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> On Wed, Sep 25, 2013 at 1:46 AM, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> wrote:<br>
>> * Import-related module attributes (other than ``__spec__``) will no<br>
>>   longer be used directly by the import system.<br>
><br>
><br>
> Might want to be clear with an example as to what happens to __path__ as that's the one value people do manipulate on occasion in order to see semantic changes. Basically ModuleSpec objects are bundles of data for importing a single module that the ModuleSpec describes, but they don't play a role in other modules' imports, thus not influencing submodules.</p>

<p dir="ltr">Good point.</p>
<p dir="ltr">>> How Loading Will Work<br>
>> =====================<br>
>><br>
>> This is an outline of what happens in ModuleSpec's loading<br>
>> functionality::<br>
>><br>
>>    def load(spec):<br>
>>        if not hasattr(spec.loader, 'exec_module'):<br>
>>            module = spec.loader.load_module(<a href="http://spec.name">spec.name</a>)<br>
>>            spec.init_module_attrs(module)<br>
>>            return sys.modules[<a href="http://spec.name">spec.name</a>]<br>
>><br>
>>        module = None<br>
>>        if hasattr(spec.loader, 'create_module'):<br>
>>            module = spec.loader.create_module(spec)<br>
>>        if module is None:<br>
>>            module = ModuleType(<a href="http://spec.name">spec.name</a>)<br>
>>        spec.init_module_attrs(module)<br>
>><br>
>>        sys.modues[<a href="http://spec.name">spec.name</a>] = module<br>
>>        try:<br>
>>            spec.loader.exec_module(module)<br>
>>        except Exception:<br>
>>            del sys.modules[<a href="http://spec.name">spec.name</a>]<br>
>>            raise<br>
>>        return sys.modules[<a href="http://spec.name">spec.name</a>]<br>
><br>
><br>
> try:<br>
>   spec.loader.exec_module(module) <br>
> except BaseException:<br>
>   try:<br>
>     del sys.modules[<a href="http://spec.name">spec.name</a>]<br>
>   except KeyError:<br>
>     pass</p>
<p dir="ltr">Fair enough.</p>
<p dir="ltr">>> The following ModuleSpec methods are not part of the public API since<br>
>> it is easy to use them incorrectly and only the import system really<br>
>> needs them (i.e. they would be an attractive nuisance).<br>
>><br>
>> * _create() - provide a new module to use for loading.<br>
>> * _exec(module) - execute the spec into a module namespace.<br>
>> * _load() - prepare a module and execute it in a protected way.<br>
>> * _reload(module) - re-execute a module in a protected way.<br>
><br>
><br>
> Do these really need to be documented as not part of the API? They have leading underscores and so as per PEP 8 they are implicitly not part of the public API. They then just feel like noise and something that should not be explained as part of the specification.</p>

<p dir="ltr">I'm fine with removing them from the PEP.</p>
<p dir="ltr">>> .. [lazy_import_concerns] <a href="https://mail.python.org/pipermail/python-dev/2013-August/128129.html">https://mail.python.org/pipermail/python-dev/2013-August/128129.html</a><br>
><br>
><br>
> I should mention that this PEP will actually improve the situation for lazy loading compared to how it is in Python 3.3 when using __getattribute__. Because import now tries to backfill attributes like __package__ and __loader__, any module that is lazy based on attribute access automatically gets loaded by import itself. But with this PEP we can change import's semantics to not do that with spec-loaded modules and thus loader.exec_module() can insert a lazy module into sys.modules and know that it's attributes won't be touched unless you do a ``from ... import`` on it.</p>

<p dir="ltr">Yeah, I'm mostly focused on addressing concerns.  Would a lazy load example be worth adding to the PEP?</p>
<p dir="ltr">-eric </p>