Change in behaviour Python 3.7 > 3.8
Frank Millman
frank at chagford.com
Fri Feb 7 00:27:21 EST 2020
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
More information about the Python-list
mailing list