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

[Nick Coghlan]

On 28 Aug 2013 18:53, "Eric Snow" <ericsnowcurrently at gmail.com> wrote:
>
>
>
>
> On Sat, Aug 24, 2013 at 5:50 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 16 August 2013 01:59, Nick Coghlan <ncoghlan at gmail.com> 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.
>
>
> Okay, I'm sold.  For now I'm calling it "loading_info", but that name
sounds kind of lame.

I realised that if we're going to allow mutating the spec in create, we're
going to have to promise not to reuse them across load calls. So loaders
can be shared, but specs can't.

> FYI, I have an update of the PEP up.  I've posted it to this list so it
may show up in a day or two. <wink>

Heh :)

Cheers,
Nick.

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