On 1/3/07, Matt Draisey <matt@draisey.ca> wrote:
A while ago, I developed a small PyGtk programme that could dynamically reload all the working callbacks and logic while the GUI was still running. I could get away with this because of the flexible way Python loads modules at runtime, but it ended up being a waste of time as implementing it took more time that actually using it. For sanity's sake it quickly becomes clear you almost never want to rely on being able to refer to a half initialized module. And wouldn't it be nice if Python enforced this.
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". My suggestion is that module importing occur in a temporary local
namespace that exists only until the end of the module code is executed, then a small function could copy everything from the temporary namespace into the module object. The usual closure semantics would guarantee that top-level functions could still call each other, but they would effectively become immutable after the namespace wraps up.
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. The 'global'
keyword could be used at the top level in a module to force it to be defined in the module immediately, and to ensure internal references to the object go through the module object.
This would be a big change in module import semantics, but should have remarkably few consequences, as it really is an enforcement mechanism for good style. The copying from the temporary namespace into the module object would be a good place to insert a hook function to filter what objects are actually published to the module. You could by default not copy any object indentified by a leading underscore.
Private namespaces are not exactly a popular thing in Python. =) -Brett