Re: Change in behaviour Python 3.7 > 3.8
> On 7 Feb 2020, at 05:27, Frank Millman wrote: > > @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. I have faced the same problem with leaking of objects. What I did was use the python gc to find all the objects. First I call gc.collect() to clean up all the objects what can be deleted. Then I call gc.get_objects() to get a list of all the objects the gc is tracking. I process that list into a collections.Counter() with counts of each type of object that I call a snapshot. By creating the snapshots at interesting times in the services life I can diff the snapshots and see how the object usage changes over time. The software I work on has an admin HTTP interface used internally that I use to request snapshots white the service is running. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: Change in behaviour Python 3.7 > 3.8
On 2020-02-07 1:06 PM, Barry Scott wrote: On 7 Feb 2020, at 05:27, Frank Millman wrote: @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. I have faced the same problem with leaking of objects. What I did was use the python gc to find all the objects. First I call gc.collect() to clean up all the objects what can be deleted. Then I call gc.get_objects() to get a list of all the objects the gc is tracking. I process that list into a collections.Counter() with counts of each type of object that I call a snapshot. By creating the snapshots at interesting times in the services life I can diff the snapshots and see how the object usage changes over time. The software I work on has an admin HTTP interface used internally that I use to request snapshots white the service is running. This is really useful. I will experiment with this and try to incorporate it into my project. Thanks very much. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: Documentation of __hash__
On 2/6/20 2:13 PM, klau...@gmail.com wrote: The default __eq__ method (object identity) is compatible with all (reasonable) self-defined __hash__ method. Stefan If __eq__ compares just the id, then the only hash you need is the default that is also the id. If you define a separate hash function, which uses some of the 'value' of the object, then presumably you intend for objects where that 'value' matches to be equal, which won't happen with the default __eq__. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Change in behaviour Python 3.7 > 3.8
07.02.20 07:27, Frank Millman ะฟะธัะต: @Serhiy I import the common object *from* Module A. Sorry, I incorrectly described the change made in issue1. Even if you import it from module A, you can see that it was set to None at the time of executing __del__. But you could see this even before issue1. It was just your luck that you did not fail before. The robust way of solving such issues is to keep a reference to all objects used in __del__: def __del__(self, common_object=common_object): ... -- https://mail.python.org/mailman/listinfo/python-list
Re: Documentation of __hash__
On Fri, Feb 7, 2020, at 10:14, Richard Damon wrote: > On 2/6/20 2:13 PM, klau...@gmail.com wrote: > > The default __eq__ method (object identity) is compatible with all > > (reasonable) self-defined __hash__ method. > > > > Stefan > > If __eq__ compares just the id, then the only hash you need is the > default that is also the id. If you define a separate hash function, > which uses some of the 'value' of the object, then presumably you intend > for objects where that 'value' matches to be equal, which won't happen > with the default __eq__. I think Stefan's point is that, no matter how questionable the intent may sound, any deterministic __hash__ doesn't technically violate the hash/eq relationship with the default __eq__, because hash(x) will still be equal to hash(x). Only defining __eq__ can create the problem where x == y but hash(x) != hash(y). The purpose of this rule is to save you from having to override the default __hash__ with something that will only raise an exception when you do not intend your class to be hashable. -- https://mail.python.org/mailman/listinfo/python-list
RE: Change in behaviour Python 3.7 > 3.8
Does anyone know of a service where I can send my STL files and have them converted to .x3g file, so I can simply upload the file to my SD card and run the parts in my Printer (Creator Pro Flashforge). I have had no success in doing this and converting to the G-code required for my machine... Thanks, Bill O. -Original Message- From: Python-list On Behalf Of Souvik Dutta Sent: Thursday, February 6, 2020 8:48 AM To: Frank Millman Cc: python-list@python.org Subject: 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Change in behaviour Python 3.7 > 3.8
On 02/07/2020 09:13 AM, bill.orin...@gmail.com wrote: Does anyone know of a service where I can send my STL files and have them converted to .x3g file, so I can simply upload the file to my SD card and run the parts in my Printer (Creator Pro Flashforge). I have had no success in doing this and converting to the G-code required for my machine... Hopefully you sent this email to the wrong place. python-list@python.org is for discussion of things related to the Python Programming Language. Also, please start a new thread instead of piggy-backing on an existing thread. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
