<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 28, 2013 at 12:04 PM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5">On Wed, Aug 28, 2013 at 8:43 AM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></span> wrote:<br>

</div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p dir="ltr">On Aug 28, 2013 3:26 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>



> 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.</p>
</div><p dir="ltr">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</p>


</blockquote></div></div><div>I see three options:</div><div><br></div><div>1. We advise against calling Modulespec.create() and ModuleSpec.load() more than once.</div><div>2. ModuleSpec's create() and load() programmatically disallow (or otherwise handle) being called more than once.</div>


<div>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?</div><div><br></div><div>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.</div>

</div></div></div></blockquote><div><br></div><div>Isn't that the point of reload() sans the blind return? This is heading down the road of trying to worry about stuff that will likely never happen except by people trying to bypass the import system and thus are just asking to get screwed up. We shouldn't bend over to block or (or support it).</div>

<div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>  And create() would simply return a new, prepared module, with special handling for the Loader.create_module() exceptional case.</div>


<div><br></div><div>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()).</div>

<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-eric</div></font></span></div></div></div>
<br>_______________________________________________<br>
Import-SIG mailing list<br>
<a href="mailto:Import-SIG@python.org">Import-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/import-sig" target="_blank">http://mail.python.org/mailman/listinfo/import-sig</a><br>
<br></blockquote></div><br></div></div>