[PyKDE] destructor not getting called?
kpederson at mail.ewu.edu
Fri Nov 8 17:33:15 GMT 2002
On Friday 08 November 2002 07:42, Kaleb Pederson wrote:
On Thursday 07 November 2002 10:14 pm, Boudewijn Rempt wrote:
> Hmmm... What I do is to create a Python class with the settings as
> 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
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
More information about the PyQt