Change in behaviour Python 3.7 > 3.8
Hi all I have noticed a change in behaviour in Python 3.8 compared with previous versions of Python going back to at least 2.7. I am pretty sure that it is not a problem, and is caused by my relying on a certain sequence of events at shutdown, which of course is not guaranteed. However, any change in behaviour is worth reporting, just in case it was unintended, so I thought I would mention it here. 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(). Module B defines a Class, and creates a global instance of this class when the module is created. This instance is never explicitly deleted, so I assume it gets implicitly deleted at shutdown. It has a __del__() method (only for temporary debugging purposes, so will be removed for production) and the __del__ method uses the set() object imported from Module A. 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. Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
Re: Change in behaviour Python 3.7 > 3.8
> On 6 Feb 2020, at 13:01, Frank Millman wrote: > > Hi all > > I have noticed a change in behaviour in Python 3.8 compared with previous > versions of Python going back to at least 2.7. I am pretty sure that it is > not a problem, and is caused by my relying on a certain sequence of events at > shutdown, which of course is not guaranteed. However, any change in behaviour > is worth reporting, just in case it was unintended, so I thought I would > mention it here. > > 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(). > > Module B defines a Class, and creates a global instance of this class when > the module is created. This instance is never explicitly deleted, so I assume > it gets implicitly deleted at shutdown. It has a __del__() method (only for > temporary debugging purposes, so will be removed for production) and the > __del__ method uses the set() object imported from Module A. > > 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. I recall reading that shutdown had changed in 3.8, but cannot find the email/webpage that I read. These days I assume that __del__ will almost never be useful and use exploit calls to tell an object I am finished with it and it can do its resource clean up. Barry > > Frank Millman > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Change in behaviour Python 3.7 > 3.8
You might find this helpful. https://docs.python.org/3/reference/datamodel.html Thank you 😊😙 On Thu, Feb 6, 2020, 6:29 PM Frank Millman wrote: > Hi all > > I have noticed a change in behaviour in Python 3.8 compared with > previous versions of Python going back to at least 2.7. I am pretty sure > that it is not a problem, and is caused by my relying on a certain > sequence of events at shutdown, which of course is not guaranteed. > However, any change in behaviour is worth reporting, just in case it was > unintended, so I thought I would mention it here. > > 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(). > > Module B defines a Class, and creates a global instance of this class > when the module is created. This instance is never explicitly deleted, > so I assume it gets implicitly deleted at shutdown. It has a __del__() > method (only for temporary debugging purposes, so will be removed for > production) and the __del__ method uses the set() object imported from > Module A. > > 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. > > Frank Millman > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Change in behaviour Python 3.7 > 3.8
06.02.20 14:58, Frank Millman пише: I have noticed a change in behaviour in Python 3.8 compared with previous versions of Python going back to at least 2.7. I am pretty sure that it is not a problem, and is caused by my relying on a certain sequence of events at shutdown, which of course is not guaranteed. However, any change in behaviour is worth reporting, just in case it was unintended, so I thought I would mention it here. 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(). Module B defines a Class, and creates a global instance of this class when the module is created. This instance is never explicitly deleted, so I assume it gets implicitly deleted at shutdown. It has a __del__() method (only for temporary debugging purposes, so will be removed for production) and the __del__ method uses the set() object imported from Module A. 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. Do you import a common object *from* a module or import a module and access a common object as its attribute? If the latter, the change may be related to https://bugs.python.org/issue1 . Modules are now cleaned up in the reversed order of importing. In any case, the order of cleaning up modules is not specified/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Documentation of __hash__
The default __eq__ method (object identity) is compatible with all (reasonable) self-defined __hash__ method. Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Change in behaviour Python 3.7 > 3.8
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
