Re: __init__ vs. __del__
2009/3/21 Randy Turner rtms...@yahoo.com: There are a number of use-cases for object cleanup that are not covered by a generic garbage collector... For instance, if an object is caching data that needs to be flushed to some persistent resource, then the GC has no idea about this. It seems to be that for complex objects, clients of these objects will need to explictly call the objects cleanup routine in some type of finally clause, that is if the main thread of execution is some loop that can terminate either expectedly or unexpectedly Relying on a generic GC is only for simple object cleanup...at least based on what I've read so far. Someone mentioned a context manager earlier...I may see what this is about as well, since I'm new to the language. If you add a .close method to your class you can use contextlib.closing[0]. I have used this to clean up distributed locks and other non-collectable resources. 0. http://docs.python.org/library/contextlib.html#contextlib.closing -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek -- http://mail.python.org/mailman/listinfo/python-list
Re: __init__ vs. __del__
__init__ is the object construction(initialization) faze __del__ is the object destruction faze, I think GC also happens, not sure -Alex Goretoy http://www.goretoy.com -- http://mail.python.org/mailman/listinfo/python-list
Re: __init__ vs. __del__
Randy Turner wrote: I was reading a book on Python-3 programming recently and the book stated that, while there is an __init__ method for initializing objects, there was a __del__ method but the __del__ method is not guaranteed to be called when an object is destroyed. If there is code in the __init__ method that allocates resources (memory, file opens, etc.), how do these resources get cleaned up when an object is destroyed? Custom method? At the moment, this architecture seems a bit asymmetric if the __del__ method is not called. The issue isn't as pressing as you may think. __init__() and __del__() aren't the constructor and destructor of an object. They are the initializer and finalizer of an object. The constructor is the __new__ function of a type. It's possible to construct an object without having it's __init__() method called. Since resources like memory, file handles and other stuff are usually handled in C code, the type definition provides a rich set of API methods. Objects that deal with resources like e.g. a database connection are usually implemented in C, too. I suggest that you read up the functions here: http://docs.python.org/c-api/typeobj.html#tp_new http://docs.python.org/c-api/typeobj.html#tp_init http://docs.python.org/c-api/typeobj.html#tp_alloc http://docs.python.org/c-api/typeobj.html#tp_dealloc http://docs.python.org/c-api/typeobj.html#tp_free __del__ is only problematic when the object is part of a reference cycle. When the object isn't or can't be part of a cycle the __del__ method is called. -- http://mail.python.org/mailman/listinfo/python-list
Re: __init__ vs. __del__
On Mar 21, 8:37 pm, Christian Heimes li...@cheimes.de wrote: Randy Turner wrote: I was reading a book on Python-3 programming recently and the book stated that, while there is an __init__ method for initializing objects, there was a __del__ method but the __del__ method is not guaranteed to be called when an object is destroyed. If there is code in the __init__ method that allocates resources (memory, file opens, etc.), how do these resources get cleaned up when an object is destroyed? Custom method? At the moment, this architecture seems a bit asymmetric if the __del__ method is not called. If you have resources in Python that need reliable open/close, lock/ unlock, etc. symmetry, use the with statement or try-finally in your Python code. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: __init__ vs. __del__
On Sat, 2009-03-21 at 17:41 -0700, Randy Turner wrote: Hi, I was reading a book on Python-3 programming recently and the book stated that, while there is an __init__ method for initializing objects, there was a __del__ method but the __del__ method is not guaranteed to be called when an object is destroyed. If there is code in the __init__ method that allocates resources (memory, file opens, etc.), how do these resources get cleaned up when an object is destroyed? Custom method? __del__ is called when the garbage collector is about to destroy an object. There are times when it may not be called like IIRC when the interpreter exits before an object is garbage collected or when there is an exception that causes the object's reference count to stay 0, however... In practice you rarely need to implement a __del__ method. Memory is handled by the garbage collector. Most of the time you need not deal with it and in the rare chance that you do there is a module to interface with the interpreter's garbage collector. File descriptors, network connections and the like are usually handled either with an explicit .close() on the object or by implementing/using context managers[1]. And of course if you don't do so yourself then when the interpreter exits the OS closes them implicitly. 1. http://docs.python.org/library/stdtypes.html#context-manager-types -- http://mail.python.org/mailman/listinfo/python-list
Re: __init__ vs. __del__
There are a number of use-cases for object cleanup that are not covered by a generic garbage collector... For instance, if an object is caching data that needs to be flushed to some persistent resource, then the GC has no idea about this. It seems to be that for complex objects, clients of these objects will need to explictly call the objects cleanup routine in some type of finally clause, that is if the main thread of execution is some loop that can terminate either expectedly or unexpectedly Relying on a generic GC is only for simple object cleanup...at least based on what I've read so far. Someone mentioned a context manager earlier...I may see what this is about as well, since I'm new to the language. Thanks! Randy From: Albert Hopkins mar...@letterboxes.org To: python-list@python.org Sent: Saturday, March 21, 2009 6:45:20 PM Subject: Re: __init__ vs. __del__ On Sat, 2009-03-21 at 17:41 -0700, Randy Turner wrote: Hi, I was reading a book on Python-3 programming recently and the book stated that, while there is an __init__ method for initializing objects, there was a __del__ method but the __del__ method is not guaranteed to be called when an object is destroyed. If there is code in the __init__ method that allocates resources (memory, file opens, etc.), how do these resources get cleaned up when an object is destroyed? Custom method? __del__ is called when the garbage collector is about to destroy an object. There are times when it may not be called like IIRC when the interpreter exits before an object is garbage collected or when there is an exception that causes the object's reference count to stay 0, however... In practice you rarely need to implement a __del__ method. Memory is handled by the garbage collector. Most of the time you need not deal with it and in the rare chance that you do there is a module to interface with the interpreter's garbage collector. File descriptors, network connections and the like are usually handled either with an explicit .close() on the object or by implementing/using context managers[1]. And of course if you don't do so yourself then when the interpreter exits the OS closes them implicitly. 1. http://docs.python.org/library/stdtypes.html#context-manager-types -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
