unloading a module created with imp.new_module

Patrick Stinson patrickkidd at gmail.com
Tue Nov 25 07:48:27 CET 2014

> On Nov 24, 2014, at 6:12 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Nov 24, 2014 1:27 AM, "Patrick Stinson" <patrickkidd at gmail.com <mailto:patrickkidd at gmail.com>> wrote:
> >
> > How does the __del__ method have a reference to the module’s globals dict? because it references the print function?
> The module's dict becomes the __globals__ dict used by the function for looking up globals and builtins.
Wow, that’s very helpful and good to know. Funny I never ran into that when doing this via an extensive CPython embedding project. Or maybe I ignored it.
> > Crazy. Is there any other way to comfort when a module is being deleted beside defining a class object with a printing dtor?
> Modules don't strictly have to be ModuleType. You could substitute a class with a __del__ method for the module itself for testing this. Be careful with leaving this in your production code though, as the presence of __del__ methods can interfere with garbage collection and are not advisable prior to 3.4.
> You can also test whether an object is still in memory by looking for it in gc.get_objects() although be warned that is an expensive call.
Interesting concept. One thing I am doing is allowing one script to import another by name. So in my gui I’ll have a panel for each script with a line edit to set the name, which then generates an appropriate slug. Is it still possible to import non-module objects? I guess this question is just for fun now :)

> -- 
> https://mail.python.org/mailman/listinfo/python-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20141124/9138d93c/attachment.html>

More information about the Python-list mailing list