Re: latest update of PEP 451

On Sep 25, 2013 7:05 AM, "Brett Cannon" <[email protected]> wrote:
> On Wed, Sep 25, 2013 at 1:46 AM, Eric Snow <[email protected]>
wrote:
>> * Import-related module attributes (other than ``__spec__``) will no
>>   longer be used directly by the import system.
>
>
> 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.

Good point.

>> How Loading Will Work
>> =====================
>>
>> This is an outline of what happens in ModuleSpec's loading
>> functionality::
>>
>>    def load(spec):
>>        if not hasattr(spec.loader, 'exec_module'):
>>            module = spec.loader.load_module(spec.name)
>>            spec.init_module_attrs(module)
>>            return sys.modules[spec.name]
>>
>>        module = None
>>        if hasattr(spec.loader, 'create_module'):
>>            module = spec.loader.create_module(spec)
>>        if module is None:
>>            module = ModuleType(spec.name)
>>        spec.init_module_attrs(module)
>>
>>        sys.modues[spec.name] = module
>>        try:
>>            spec.loader.exec_module(module)
>>        except Exception:
>>            del sys.modules[spec.name]
>>            raise
>>        return sys.modules[spec.name]
>
>
> try:
>   spec.loader.exec_module(module)
> except BaseException:
>   try:
>     del sys.modules[spec.name]
>   except KeyError:
>     pass

Fair enough.

>> The following ModuleSpec methods are not part of the public API since
>> it is easy to use them incorrectly and only the import system really
>> needs them (i.e. they would be an attractive nuisance).
>>
>> * _create() - provide a new module to use for loading.
>> * _exec(module) - execute the spec into a module namespace.
>> * _load() - prepare a module and execute it in a protected way.
>> * _reload(module) - re-execute a module in a protected way.
>
>
> 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.

I'm fine with removing them from the PEP.

>> .. [lazy_import_concerns]
https://mail.python.org/pipermail/python-dev/2013-August/128129.html
>
>
> 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.

Yeah, I'm mostly focused on addressing concerns.  Would a lazy load example
be worth adding to the PEP?

-eric

_______________________________________________
Import-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/import-sig