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

On Thu, Aug 15, 2013 at 9:23 AM, Nick Coghlan <[email protected]> wrote:

> 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,


I was messing around with this a while back and the thread-local context
approach was pretty easy to do.


> 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.
>

Ah. That helps clarify things.  I'll got stew on that a bit.

-eric

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