On 2020-02-06 2:58 PM, Frank Millman wrote:
[...]
I have a module (A) containing common objects shared by other modules. I
have a module (B) which imports one of these common objects - a set().
[...]
This has worked for years, but now when the __del__ method is called,
the common object, which was a set(), has become None.
My assumption is that Module A gets cleaned up before Module B, and when
Module B tries to access the common set() object it no longer exists.
I have a workaround, so I am just reporting this for the record.
Thanks to all for the replies.
@Serhiy
I import the common object *from* Module A.
@Dennis
Thanks for the references. I knew that __del__() should not be relied
on, but I have not seen the reasons spelled out so clearly before.
@Barry
I agree that __del__() is rarely useful, but I have not come up with an
alternative to achieve what I want to do. My app is a long-running
server, and creates many objects on-the-fly depending on user input.
They should be short-lived, and be removed when they go out of scope,
but I can concerned that I may leave a dangling reference somewhere that
keeps one of them alive, resulting in a memory leak over time. Creating
a _del__() method and displaying a message to say 'I am being deleted'
has proved effective, and has in fact highlighted a few cases where
there was a real problem.
My solution to this particular issue is to explicitly delete the global
instance at program end, so I do not rely on the interpreter to clean it
up. It works.
Thanks again
Frank
--
https://mail.python.org/mailman/listinfo/python-list
