<br><br><div><span class="gmail_quote">On 1/3/07, <b class="gmail_sendername">Matt Draisey</b> <<a href="mailto:matt@draisey.ca">matt@draisey.ca</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A while ago, I developed a small PyGtk programme that could dynamically<br>reload all the working callbacks and logic while the GUI was still<br>running.  I could get away with this because of the flexible way Python<br>loads modules at runtime, but it ended up being a waste of time as
<br>implementing it took more time that actually using it.  For sanity's<br>sake it quickly becomes clear you almost never want to rely on being<br>able to refer to a half initialized module.  And wouldn't it be nice if
<br>Python enforced this.</blockquote><div><br>How are you having an issue with a partially initialized module?  The only way I can see that happening is that you have a circular import dependency where both modules want to execute code that the other one has.  And if that happens the answer for that is "don't do it".
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">My suggestion is that module importing occur in a temporary local<br>namespace that exists only until the end of the module code is executed,
<br>then a small function could copy everything from the temporary namespace<br>into the module object.  The usual closure semantics would guarantee<br>that top-level functions could still call each other, but they would<br>
effectively become immutable after the namespace wraps up.</blockquote><div><br>But why would you want it to be immutable?  Being able to change the function in a module and have all uses of it also change can be handy.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  The 'global'<br>keyword could be used at the top level in a module to force it to be
<br>defined in the module immediately, and to ensure internal references to<br>the object go through the module object.<br><br>This would be a big change in module import semantics, but should have<br>remarkably few consequences, as it really is an enforcement mechanism
<br>for good style.  The copying from the temporary namespace into the<br>module object would be a good place to insert a hook function to filter<br>what objects are actually published to the module.  You could by default
<br>not copy any object indentified by a leading underscore.</blockquote><div><br>Private namespaces are not exactly a popular thing in Python.  =)<br></div><br>-Brett<br></div>