[PyKDE] destructor not getting called?

[Kaleb Pederson]

On Friday 08 November 2002 07:42, Kaleb Pederson wrote:
On Thursday 07 November 2002 10:14 pm, Boudewijn Rempt wrote:

> <snip>
>
> Hmmm... What I do is to create a Python class with the settings as
member
> variables. That makes it easier. But still, the Qt documentation says:
>
> A typical usage pattern for application exit or 'save preferences': 
>
>    QSettings settings;
>    settings.insertSearchPath( QSettings::Windows, "/MyCompany" );
>    // No search path needed for Unix; see notes further on.
>    settings.writeEntry( "/MyApplication/background color", bgColor );
>    settings.writeEntry( "/MyApplication/geometry/width", width );
>    // ...
>
> So, depending on the destructor is not the only way to go.

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.  In fact, I have almost exactly what you mentioned.  I have
a class that wraps it and provides some convenience functions for me.  I
added in some print statements so I *know* that settings.write[Num]Entry
is getting called with all the correct values.

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.

Is there a way that I can purposefully circumvent the destructor of a
PyQt object?  In my application, I simply let the module level global go
out of scope assuming that the destructor would get called; it never
does.

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.

--Kaleb