Christopher J. Bottaro wrote:
Jeff Shannon wrote:
Python's __del__() is not a C++/Java destructor.
Learn something new everyday... What is it then? Excuse my ignorance, but
what are you suppose to do if your object needs to clean up when its no
longer used (like close open file handles, etc)?
Well, those "open file handles" are presumably wrapped by file objects. Those file objects will close the underlying file handle as they are deallocated. This means that the only time you really need to worry about closing a file handle is if you want to reopen that same file immediately -- and in that case, __del__() can't help you because you can't know whether or not another reference to the file object exists somewhere else, so you'll have to explicitly close() the file anyhow. The same goes for sockets.
Are you use supposed to
make a method called Destroy() or something and require users to call it
when the object is about to be deleted? That seems to put the burdon of
ref counting on the user.
Python's refcounting/GC scheme is such that you rarely actually need to explicitly destroy an object. Unlike C++, you're not actually freeing memory, and most of the resources that you might be using are already wrapped by an object that will finalize itself properly without being explicitly destroyed. Thanks to GC and the possibility of needing to break cycles, there's not much that you can guarantee about __del__() ... but there's not much that you *need* to do in __del__().
It just seems like kinda a pain when a C++/Java style destructor would nicely do what is desired. Should I just stop digging and chalk it up to a limitation of Python?
Well, I guess you could look at it as a trade-off. In C++, you can count on your destructor getting called, but you have to do your own memory management. (Note that you still can't count on heap objects that your destructor might want to use still being there -- it's just that you can *never* count on such things in C++, and are always expected to ensure these things yourself.) Python will take care of your memory for you, and it will safely handle most OS resources for you, so that you don't have to worry about them... and in return, if you have some type of resource that Python doesn't automatically handle, you need to explicitly save it yourself.
Now, while I haven't yet done anything terribly complicated nor tried to use extensive persistence, I've essentially never felt a need to use __del__() in Python, nor missed the "proper" destructor of C++. In general, cleanup takes care of itself, and in those cases where I have more demanding needs, well, it's not *that* hard to hook into application shutdown and explicitly save my data.
So, I don't think it's so much a "limitation" of Python, as it is simply a different way of handling things.
Jeff Shannon
-- http://mail.python.org/mailman/listinfo/python-list
