[PyKDE] destructor not getting called?

Kaleb Pederson kibab at icehouse.net
Fri Nov 8 16:39:01 GMT 2002


>> I agree that it shouldn't be the only way to go.  I would definitely
>> prefer to have a function that I can call that would write to disk.
The
>> source code reveals, however, that a sync() call is only done in the
>> destructor.  
>
>I've never had a problem with lost settings, so I guess the writeEntry
>method does what it needs to. I've attached the complete guiconfig.py
>class.

Thanks for attaching it.  What you have done is almost no different then
what I did.  We are both wrapping the class and using a module level
global.  I have no problem with Trolltech's design.  In a case like
this, however, I need to be guaranteed that the destructor will get
called, and I don't know how to guarantee that.

>> I guess my main question is, therefore, if I have a reference to a
PyQt
>> object, in this case QSettings, and at the close of my program the
>> destructor never gets called for the PyQt object, then there _must_
be a
>> memory leak if any memory whatsoever is allocated by that PyQt
object.
>>
>
>No, it doesn't have to be a memory leak. If the process ends, the OS
>will reclaim all the memory. It can do that without calling
destructors,
>after all, the process doesn't run anymore.

True.  I guess I always considered it a memory leak since certain buggy
OS's didn't necessarily reclaim that memory.

>> Under *nix, has anyone ever seen QSettings actually write to the
>> settings file upon a write[Num]Entry?  I have monitored the file for
>> existence upon a new write[Num]Entry and for changes upon a
>> write[Num]Entry and None have ever been made until the object goes
out
>> of scope.
>
>Maybe I was just lucky, and have the QSettings object call the
destructor.
>Anyway, it's one part of my application where I've never had problems.

Maybe.  My settings had been working great for the last couple months,
as far as I know, and they still work great in Windows.  That's why I'm
curious to test out under a different version of PyQt.

--Kaleb

PS: Sorry for my initial response not making it to the list, I sent it
using my work account, which isn't subscribed.




More information about the PyQt mailing list