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

On 15 August 2013 02:38, Eric Snow <[email protected]> wrote:
> PJE wrote:
>> I'm thinking maybe this should be parameterized to allow passing in a
>> 'modules' dictionary other than sys.modules.  This would make
>> multi-version imports or other "isolated environment" imports more
>> viable, and factor out another global element of the import system.
>> That way, if you implement an isolated module system, you don't have
>> to duplicate or subclass ModuleSpec to perform the same loading
>> functionality.
>
> Cool idea, but couldn't this wait.  I could totally see this as part of PEP
> 406 (import engine).

One of the conclusions I came to from Greg's import engine work is
that the only practical way for us to get to isolated import
subsystems is either with a Decimal style thread local context based
solution, or with a split create/exec API where the loader doesn't do
any global state manipulation at all and instead operates in a
functional mode where it just returns values based on passed in
parameters (that way the import system at least has the chance to
override __import__ before running the module code). Anything else
looks like it will be too fragile (and the latter approach doesn't
necessarily work for C extensions that do imports).

This is part of why I'm keen on having this PEP expose "create" and
"exec" as separate operations on ModuleSpec, with "load" acting solely
as a convenience function for combining them with the appropriate
sys.modules manipulation.

Cheers,
Nick.

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