Re: Round 2 for "A ModuleSpec Type for the Import System"

On 16 August 2013 01:59, Nick Coghlan <[email protected]> wrote:
> It wouldn't be a custom namespace, just a single attribute to pass
> data to the loader. It could be a dict, namespace, string, custom
> object, anything. By default, it would be None.
>
> For example, zipimporter could use it to pass the zip archive name to
> the loader directly, rather than needing to derive it from origin or
> create a custom loader for each find operation.

Having implemented the "exec" part of the C extension modifications
(see http://mail.python.org/pipermail/python-dev/2013-August/128101.html),
I'm more convinced than ever that ModuleSpec should have some kind of
a subnamespace for storing arbitrary loader specific details.
Providing such a storage location not only allows information to be
passed from the finder to the loader, but also from the create step to
the exec step in the loading process (the C extension loader would, of
necessity, find the execution entry point while determining how to
create the module. It makes sense to be able to store that somewhere
on the spec object, rather than having to go searching through the
exported symbols again in the execution step.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia