unloading a module created with imp.new_module
Patrick Stinson
patrickkidd at gmail.com
Tue Nov 25 01:48:27 EST 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