<br><div><span class="gmail_quote">On 4/12/06, <b class="gmail_sendername">&quot;Martin v. Löwis&quot;</b> &lt;<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thomas Wouters wrote:<br>&gt; Actually, no, reload() has to remove the module from sys.modules and<br>&gt; load it anew.<br><br>That's not what reload currently does for Python modules. The module<br>object stays the same (so that anybody who imported it will also see
<br>the reload's effect).<br><br>&gt; The reason for this is that any instances of types defined<br>&gt; in the module can still live, after the reload, and they would still<br>&gt; refer to their old-module-object-referring types. (And, as you said,
<br>&gt; this is a reason to keep the 'state' in module objects.)<br><br>Are you expecting that reload of an extension module will actually<br>load the current code from disk? This can't really work: on some<br>systems, you can't update the DLL while it is in use; on others,
<br>it might not be possible to load the same shared library twice.</blockquote><div><br>Well, in the case of Python modules, a reload recreates all classes, so existing instances remain instances of the old class (and typechecks by name fail in unexpected ways; you've got to love those &quot;Excected 'Foo' instance, got 'Foo' instance&quot; errors ;) I guess I was thinking we need to work around that for C modules as well, but I guess we really don't.
<br></div></div><br>-- <br>Thomas Wouters &lt;<a href="mailto:thomas@python.org">thomas@python.org</a>&gt;<br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!