Change in behaviour Python 3.7 > 3.8

[Frank Millman]

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