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

[Eric Snow]

On Wed, Aug 28, 2013 at 8:43 AM, Eric Snow <ericsnowcurrently at gmail.com>wrote:

> On Aug 28, 2013 3:26 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> > 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.
>
> The latest version of the PEP already specifies that each module will have
> its own copy, even if the spec is otherwise the same.  Perhaps it should
> also make clear that loading_info should not be shared between specs.  It
> wouldn't hurt to also say something about allowing only one call to load()
> or something along those lines
>
I see three options:

1. We advise against calling Modulespec.create() and ModuleSpec.load() more
than once.
2. ModuleSpec's create() and load() programmatically disallow (or otherwise
handle) being called more than once.
3. Dictate that Loader.create_module() must handle the case where it is
called more than once.  Fail?  Return None?  Return the same module as
before?

I'll advocate for 3 along with making sure ModuleSpec.create() correctly
handles the exceptional response of Loader.create_module().  However, the
PEP does not really specify what happens when create() and load() are
called multiple times.  That needs to be added.  I'm tempted to have load()
simply return whatever is in sys.modules and bypass loading if the module
is already loaded.  And create() would simply return a new, prepared
module, with special handling for the Loader.create_module() exceptional
case.

Really, the sticky part is the (potential) call to Loader.create_module()
in ModuleSpec.create().  Otherwise it should not matter.  ModuleSpec.exec()
should be able to be called as many times as desired, just like
Loader.load_module() (and Loader.exec_module()).

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