[Import-SIG] Round 2 for "A ModuleSpec Type for the Import System"

[Eric Snow]

Accidently sent. :P

Continuing...


> On Sun, Aug 11, 2013 at 7:03 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> > Subclassing
>>
> > -----------
>> >
>> > Subclasses of ModuleSpec are allowed, but should not be necessary.
>> > Adding functionality to a custom finder or loader will likely be a
>> > better fit and should be tried first.  However, as long as a subclass
>> > still fulfills the requirements of the import system, objects of that
>> > type are completely fine as the return value of ``find_module()``.
>>
>> We may need to do subclasses for the ABC registration backwards
>> compatibility hack.
>
>
I was thinking of registering ModuleSpec in the setter of a `loader`
property (as long as the loader's class has a `register()` method


>> >
>> > Module Objects
>> > --------------
>> >
>> > Module objects will now have a ``__spec__`` attribute to which the
>> > module's spec will be bound.  None of the other import-related module
>> > attributes will be changed or deprecated, though some of them could be;
>> > any such deprecation can wait until Python 4.
>> >
>> > ``ModuleSpec`` objects will not be kept in sync with the corresponding
>> > module object's import-related attributes.  Though they may differ, in
>> > practice they will typically be the same.
>>
>> Worth mentioning that __main__.__spec__.name will give the real name
>> of module's executed with -m here rather than delaying that until the
>> notes at the end.
>>
>
Fair enough.


>
>> > Finders
>> > -------
>> >
>> > Finders will now return ModuleSpec objects when ``find_module()`` is
>> > called rather than loaders.  For backward compatility, ``Modulespec``
>> > objects proxy the attributes of their ``loader`` attribute.
>> >
>> > Adding another similar method to avoid backward-compatibility issues
>> > is undersireable if avoidable.  The import APIs have suffered enough,
>> > especially considering ``PathEntryFinder.find_loader()`` was just
>> > added in Python 3.3.  The approach taken by this PEP should be
>> > sufficient to address backward-compatibility issues for
>> > ``find_module()``.
>> >
>> > The change to ``find_module()`` applies to both ``MetaPathFinder`` and
>> > ``PathEntryFinder``.  ``PathEntryFinder.find_loader()`` will be
>> > deprecated and, for backward compatibility, implicitly special-cased if
>> > the method exists on a finder.
>>
>> Actually, we don't currently have anything on ModuleSpec to indicate
>> "this is complete, stop scanning for more path fragments" or how we
>> will compose multiple module specs for the individual fragments into a
>> combined spec for the namespace package.
>>
>
I was planning on just using the loader's type.  If it's NamespaceLoader
then path is where we'll get the fragments.  I was going to say it's
working in my implementation, but namespace packages are actually the one
part that still have some failing tests. :P


>
>> > Finders are still responsible for creating the loader.  That loader will
>> > now be stored in the module spec returned by ``find_module()`` rather
>> > than returned directly.  As is currently the case without the PEP, if a
>> > loader would be costly to create, that loader can be designed to defer
>> > the cost until later.
>> >
>> > Loaders
>> > -------
>> >
>> > Loaders will have a new method, ``exec_module(module)``.  Its only job
>> > is to "exec" the module and consequently populate the module's
>> > namespace.  It is not responsible for creating or preparing the module
>> > object, nor for any cleanup afterward.  It has no return value.
>> >
>> > The ``load_module()`` of loaders will still work and be an active part
>> > of the loader API.  It is still useful for cases where the default
>> > module creation/prepartion/cleanup is not appropriate for the loader.
>> >
>> > For example, the C API for extension modules only supports the full
>> > control of ``load_module()``.  As such, ``ExtensionFileLoader`` will not
>> > implement ``exec_module()``.  In the future it may be appropriate to
>> > produce a second C API that would support an ``exec_module()``
>> > implementation for ``ExtensionFileLoader``.  Such a change is outside
>> > the scope of this PEP.
>>
>> As above, I think it may worth tackling this. It shouldn't be *that*
>> hard given the higher level changes and will solve some hard problems
>> at the lower level.
>>
>
For me that seems like a separate proposal.  Certainly it's related, but in
some ways it would feel tacked on.  On top of that, I'd have to dive into
the extension module API much more than I have and I'd rather get
ModuleSpec and .ref file wrapped up sooner.  At the same time, I haven't
really done much API design in C so that would be interesting.  In the end,
I'd like to keep the extension module API additions out of this PEP.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20130812/933a76a1/attachment.html>