>> 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. _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
