Re: [PyKDE] PyQt-x11-gpl-3.4/examples2/widgets.py: buggy or did I mis-install?
On Friday 08 November 2002 22:16, Phil Thompson wrote: ... > > Traceback (most recent call last): > > File "widgets.py", line 480, in lineEditTextChanged > > txt = txt + newText > > TypeError: cannot concatenate 'str' and 'instance' objects > > > > > > The other widgets appear to work fine with some cursory testing. > > It looks like you are running the Qt v2 examples instead of the Qt v3 > ones. Silly me, you're right. However, running example3/widgets.py instead STILL shows a traceback whenever I type in the edit-text: Traceback (most recent call last): File "widgets.py", line 470, in lineEditTextChanged self.msg.setText( "Line edit text: " + newText ) TypeError: cannot concatenate 'str' and 'instance' objects Alex ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyQt-x11-gpl-3.4/examples2/widgets.py: buggy or did I mis-install?
On Friday 08 November 2002 8:47 pm, Alex Martelli wrote: > I just re-installed PyQt-x11-gpl-3.4 (with Python 2.2.2 on Mandrake 9.0) > and went around trying a few examples. However examples2/widgets.py seems > to have many bugs -- or, more likely, symptoms that I mis-installed, but > I'd rather check this before I start digging into install problems. > > When I change the entry in the dropdown darkBlue / darkRed / darkGreen etc: > > Traceback (most recent call last): > File "widgets.py", line 472, in comboBoxItemActivated > QApplication.setWinStyleHighlightColor( Qt.darkGreen ) > AttributeError: setWinStyleHighlightColor > > and when I write in the entry field near the bottom of the window: > > Traceback (most recent call last): > File "widgets.py", line 480, in lineEditTextChanged > txt = txt + newText > TypeError: cannot concatenate 'str' and 'instance' objects > > > The other widgets appear to work fine with some cursory testing. It looks like you are running the Qt v2 examples instead of the Qt v3 ones. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyQt-x11-gpl-3.4/examples2/widgets.py: buggy or did I mis-install?
I just re-installed PyQt-x11-gpl-3.4 (with Python 2.2.2 on Mandrake 9.0) and went around trying a few examples. However examples2/widgets.py seems to have many bugs -- or, more likely, symptoms that I mis-installed, but I'd rather check this before I start digging into install problems. When I change the entry in the dropdown darkBlue / darkRed / darkGreen etc: Traceback (most recent call last): File "widgets.py", line 472, in comboBoxItemActivated QApplication.setWinStyleHighlightColor( Qt.darkGreen ) AttributeError: setWinStyleHighlightColor and when I write in the entry field near the bottom of the window: Traceback (most recent call last): File "widgets.py", line 480, in lineEditTextChanged txt = txt + newText TypeError: cannot concatenate 'str' and 'instance' objects The other widgets appear to work fine with some cursory testing. Thanks, Alex ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Qt shutting down the process/Python interpreter - ne
On 08-Nov-02 Michael Lauer wrote: > Now, my question... is there something I can do at python level > or is there something we can do at PyQt level to change this > behaviour? If you call sys.exit() in Python it always raises a SystemExit exception. Does that happen here? If so, you can trap it and cancel it or whatever you need to do. Is there a way you can cause SystemExit to be raised? (I'm not sure if this happens at program termination without an explicit sys.exit() call). That might also be a solution for the other people with destructor-call problems. Then again, it might not. Alternatively, can you have soemthing set a flag if QApplication launches successfully? For example: app = QApplication (...) ... while True: app.exec_loop () if flag: break You can subclass QApplication or install a temporary eventHandler if necessary. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Qt shutting down the process/Python interpreter - necessary?
It is quite reasonable for Qt to break down when fatal error occure due
to an errorneous initializing of the whole system. It's like pressing
the gas pedal of a car without ever turning the key first. Since Qt has
quite complex initializing mechnisms which optimize the work during a
running program this behaviour increases debuggability and consistency.
It is no parameter of compiled programs that they should break down on
program errors, its just a reasonable parameter of Qt not to start in
wrong environments. It is left to you to check for a server BEFORE
creating a QApplication as a client.
I also don't know where you want to put your "-qws" argument inside your
application. Though this is possible this should in neither case be
acceptable style. The QApplication class provides a constructor for
this operation and you should use that:
if QwsIsStarted(): # QwsIsStarted() is an own function that tests
# for a server, see below.
app = QApplication( argc, argv, QApplication::GuiClient )
else
app = QApplication( argc, argv, QApplication::GuiServer )
As documented in the Qt Documentation:
---
QApplication::QApplication ( int & argc, char ** argv, Type type )
Constructs an application object with argc command line arguments in argv.
For Qt/Embedded, passing QApplication::GuiServer for type makes this application the
server (equivalent to running with the -qws option).
---
On the other hand if you want to use "-qws" as an option, why don't you
start a script that restarts your application with "-qws" if the
operation fails.
There are many solutions to the problem which all rely on your knowledge
of a server running. You should think about a test function that I
called QwsIsStarted() as an example here.
BYE INGO
On Fri, Nov 08, 2002 at 12:26:54PM +0100, Michael Lauer wrote:
> Hi,
>
> in Qt there are certain places, where exit() is called, for instance,
> if you construct a QPaintDevice before a QApplication, the process ends.
>
> This behaviour - while perhaps being reasonable in a compiled language -
> seems truly inappropriate in the context of an interpretated interactive
> and dynamic environment such as the Python interpreter.
>
> It would be much more useful if this would raise an exception, like,
> PyQtException, which we could catch and react appropriate - for
> instance, generating the application object and trying again.
>
> It's especially bugging me in Qt/Embedded, where the offending exit()
> call is triggered, when you create a QApplication in client mode but
> no QWS server is running. It would be sufficient to just recreate the
> QApplication with the appropriate parameter (-qws), but I can't because
> my interpreter is being shutdown [see below] :(
>
>
>
> mickey@gandalf:~/work/elan$ python
> Python 2.2.2 (#1, Oct 27 2002, 17:30:06)
> [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import qtpe
> >>> try:
> ... a=qtpe.QApplication([])
> ... except:
> ... pass
> ...
> QSocket::writeBlock: Socket is not open
> QSocket::writeBlock: Socket is not open
> QSocket::writeBlock: Socket is not open
> No Qt/Embedded server appears to be running.
> If you want to run this program as a server,
> add the "-qws" command-line option.
> mickey@gandalf:~/work/elan$
>
>
>
> This behaviour is due to the following code:
>
>
>
> void QWSDisplayData::waitForConnection()
> {
> #ifndef QT_NO_QWS_MULTIPROCESS
> for ( int i = 0; i < 5; i++ ) {
> if ( csocket ) {
> csocket->flush();
> csocket->waitForMore(2000);
> }
> fillQueue();
> if ( connected_event )
> return;
> usleep( 5 );
> }
> #else
> if ( connected_event )
> return;
> #endif
> qWarning("No Qt/Embedded server appears to be running.");
> qWarning("If you want to run this program as a server,");
> qWarning("add the \"-qws\" command-line option.");
> exit(1);
> }
>
>
>
> Now, my question... is there something I can do at python level
> or is there something we can do at PyQt level to change this behaviour?
>
> Yours,
>
> --
> :M:
> --
> Dipl.-Inf. Michael 'Mickey' Lauer
> [EMAIL PROTECTED]
> Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie
> --
>
> ___
> PyKDE mailing list[EMAIL PROTECTED]
> http://mats.gmd.de/mailman/listinfo/pykde
>
___
PyKDE mailing list[EMAIL PROTECTED]
http://
RE: [PyKDE] destructor not getting called?
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 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 ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] destructor not getting called?
>On Fri, 2002-11-08 at 01:50, Kaleb Pederson wrote: >> I'm using a global QSettings object throughout my application. For some >> reason, when the program closes, the destructor on my QSettings object is >not > getting called. As it is the destructor that actually writes everything >to >> disk (in order to cache the data), none of my settings are getting saved. >Can >> I manually call it? I'm pretty sure that this used to work on previous >> PyQt/Qt versions. > > The reason you're having problems is most likely because there is no > such thing as a destructor in Python. I assume that you, like many > before you, are treating the __del__() method as a destructor but the > reality is there is no guarantee that __del__() will be called on > program exit. The Python Language Reference recommends that you only use > __del__() methods to "do the absolute minimum needed to maintain > external invariants". See > http://www.python.org/doc/current/ref/customization.html for more > information. That was not one of my assumptions in this case. I'm using a module level global that contains a reference to my wrapped QSettings class wherein a member variable is assigned the QSettings object. My only assumption was that once the reference count hit zero, that PyQt would call the destructor of the C++ object to avoid any memory leaks. I never explicitly call delete on the object; instead, I simply let it go out of scope at application close. Thanks for the link though. As Python has a GC, writing the __del__ call has never been a priority to me. In fact, I never considered it the destructor of an object but merely a suggestion to the GC. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] setCellWidget and signal
Dear everybody, I'm using setCellWidget() to put several buttons in cells of a table. when I capture the signal,I would like to check the button whom (row,column) the signal belongs to. Thank you for your help. David Florkin - Tiscali Complete, l'accès Internet moins cher que gratuit ! Plus d'info: http://complete.tiscali.be ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] setCellWidget and signal
Dear everybody, I'm using setCellWidget() to put several buttons on cells in a table. When I capture the signal, I would like to check the button whom(row,column) the signal belongs to. Thank you for your help. David Florkin ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] destructor not getting called?
>> 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
Re: [PyKDE] destructor not getting called?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 08 November 2002 15:38, you wrote:
>
> 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.
> 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.
>
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.
> 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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9y82BdaCcgCmN5d8RAlO6AJ4mPmNnx0sT6p+6y3w6BdrqPFUL5ACgn0s8
Cg9cuwglgc+i09DfBu6KPzs=
=mH/R
-END PGP SIGNATURE-
""" guiconfig.py
Configuration settings for the Kura GUI. Uses the Qt.QSettings class.
"""
import sys, os
from qt import QSettings, QFont
TEXT = 0
NUM = 1
ILVIEW = 0
TREEVIEW = 1
XMLVIEW = 2
FILE="TextQuery"
SQL="dbSql"
tables = [
"lng_project",
"lng_user",
"lng_document",
"lng_doc_doc",
"lng_doc_refs",
"lng_linkcode",
"lng_language",
"lng_reference",
"lng_proj_user",
"lng_proj_lngg",
"lng_recording",
"lng_scan",
"lng_text",
"lng_proj_text",
"lng_stream",
"lng_element",
"lng_lex",
"lng_lex_lex",
"lng_lxlxrelcode",
"lng_text_tag",
"lng_stream_tag",
"lng_element_tag",
"lng_lex_tag",
"lng_tag",
"lng_tagtypecode",
"lng_tagdomain",
"lng_affiliationcode",
"lng_elementtypecode",
"lng_categorycode"]
defaults = {
"textselectorwidth": (NUM, "/kura/lng_text/selector/width", 120),
"interlinearstyle": (NUM, "/kura/export/interlinear", 1),
"backend": (TEXT, "/kura/backend", FILE),
"datastore": (TEXT, "/kura/backend/store", "new.dbobj"),
"filepath": (TEXT, "/kura/backend/filepath", os.environ["HOME"]),
"database" : (TEXT, "/kura/database/database", "andal"),
"hostname" : (TEXT, "/kura/database/hostname", "localhost"),
"password" : (TEXT, "/kura/database/password", ""),
"username" : (TEXT, "/kura/database/username", ""),
"usernr" : (NUM, "/kura/defaults/usernr", 0),
"languagenr" : (NUM, "/kura/defaults/languagenr", 0),
"projectnr" : (NUM, "/kura/defaults/projectnr", 0),
"textfontfamily" : (TEXT, "/kura/defaults/textfont/family", "unifont"),
"textfontsize" : (NUM, "/kura/defaults/textfont/size", 16),
"app_w" : (NUM, "/kura/geometry/app_w", 640),
"app_h" : (NUM, "/kura/defaults/app_h", 640),
"app_x" : (NUM, "/kura/geometry/app_x", 0),
"app_y" : (NUM, "/kura/geometry/app_y", 0),
"widgetfontfamily" : (TEXT, "/kura/defaults/widgetfont/family",
"helvetica"),
"widgetfontsize" : (NUM, "/kura/defaults/widgetfont/size", 16),
"currentTableName" : (TEXT, "/kura/defaults/currentview/tablename",
"lng_lex"),
"useDefaultForSearch" : (NUM, "/kura/defaults/usedefaultforsearch", 0),
"ShowValueHint" : (NUM, "/kura/defaults/showvaluehint", 0),
"streamRegExp" : (TEXT, "/kura/defaults/stream/streamRegExp",
"\. |\.\n|[!?\12]"),
"elementRegExp" : (TEXT, "/kura/defaults/element/elementRegExp",
'=--|[ ,:;"]'),
"morphemeRegExp" : (TEXT, "/kura/defaults/element/morphemeRegExp", "[.]")
}
def __readAndSetEntry(key, pos, default):
d, ok = guiConf.readNumEntry("/kura/dialog/%s/%s" % (key, pos), default)
setattr(guiConf, unicode("%s_%s" % (key, pos)), d)
def initialize():
if sys.platform[:3] == 'win':
guiConf.insertSearchPath(QSettings.Windows, "Kura")
for k, v in defaults.items():
if v[0] == TEXT:
d, ok = guiConf.readEntry(v[1], v[2])
setattr(guiConf, unicode(k), unicode(d))
elif v[0] == NUM:
d, ok =
[PyKDE] Qt shutting down the process/Python interpreter - necessary?
Hi,
in Qt there are certain places, where exit() is called, for instance,
if you construct a QPaintDevice before a QApplication, the process ends.
This behaviour - while perhaps being reasonable in a compiled language -
seems truly inappropriate in the context of an interpretated interactive
and dynamic environment such as the Python interpreter.
It would be much more useful if this would raise an exception, like,
PyQtException, which we could catch and react appropriate - for
instance, generating the application object and trying again.
It's especially bugging me in Qt/Embedded, where the offending exit()
call is triggered, when you create a QApplication in client mode but
no QWS server is running. It would be sufficient to just recreate the
QApplication with the appropriate parameter (-qws), but I can't because
my interpreter is being shutdown [see below] :(
mickey@gandalf:~/work/elan$ python
Python 2.2.2 (#1, Oct 27 2002, 17:30:06)
[GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import qtpe
>>> try:
... a=qtpe.QApplication([])
... except:
... pass
...
QSocket::writeBlock: Socket is not open
QSocket::writeBlock: Socket is not open
QSocket::writeBlock: Socket is not open
No Qt/Embedded server appears to be running.
If you want to run this program as a server,
add the "-qws" command-line option.
mickey@gandalf:~/work/elan$
This behaviour is due to the following code:
void QWSDisplayData::waitForConnection()
{
#ifndef QT_NO_QWS_MULTIPROCESS
for ( int i = 0; i < 5; i++ ) {
if ( csocket ) {
csocket->flush();
csocket->waitForMore(2000);
}
fillQueue();
if ( connected_event )
return;
usleep( 5 );
}
#else
if ( connected_event )
return;
#endif
qWarning("No Qt/Embedded server appears to be running.");
qWarning("If you want to run this program as a server,");
qWarning("add the \"-qws\" command-line option.");
exit(1);
}
Now, my question... is there something I can do at python level
or is there something we can do at PyQt level to change this behaviour?
Yours,
--
:M:
--
Dipl.-Inf. Michael 'Mickey' Lauer
[EMAIL PROTECTED]
Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie
--
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] destructor not getting called?
On Friday 08 November 2002 01:59 am, Fredrik Juhlin wrote: > On Fri, 2002-11-08 at 10:34, Greg Fortune wrote: > > On Friday 08 November 2002 12:44 am, you wrote: > > > The reason you're having problems is most likely because there is no > > > such thing as a destructor in Python. I assume that you, like many > > > before you, are treating the __del__() method as a destructor but the > > > reality is there is no guarantee that __del__() will be called on > > > program exit. The Python Language Reference recommends that you only > > > use > > > > ack, where did you find information implying that __del__ might not > > get called on program exit? From my understanding, __del__ just wouldn't > > be called until the reference count reaches 0 and the garbage collection > > cycle executes. That, of course, should happen for every object at > > program exit... If it doesn't, that would seem like a Python bug. > > I got it from the Python Language Reference (a convenient link was > included in my last mail and below). To quote: > "It is not guaranteed that __del__() methods are called for objects that > still exist when the interpreter exits." > Wether or not it is a bug I'm really not qualified to say. Looks like I skimmed right over that to the Warning section and figured that's what you were talking about. I see it now and feel just a tad silly ;o) If it's a bug, it's a documented one... > > > > __del__() methods to "do the absolute minimum needed to maintain > > > external invariants". See > > > http://www.python.org/doc/current/ref/customization.html for more > > > information. > > //Fredrik > > ___ > PyKDE mailing list[EMAIL PROTECTED] > http://mats.gmd.de/mailman/listinfo/pykde ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] destructor not getting called?
On Fri, 2002-11-08 at 10:34, Greg Fortune wrote: > On Friday 08 November 2002 12:44 am, you wrote: > > The reason you're having problems is most likely because there is no > > such thing as a destructor in Python. I assume that you, like many > > before you, are treating the __del__() method as a destructor but the > > reality is there is no guarantee that __del__() will be called on > > program exit. The Python Language Reference recommends that you only use > > ack, where did you find information implying that __del__ might not get > called on program exit? From my understanding, __del__ just wouldn't be > called until the reference count reaches 0 and the garbage collection cycle > executes. That, of course, should happen for every object at program exit... > If it doesn't, that would seem like a Python bug. I got it from the Python Language Reference (a convenient link was included in my last mail and below). To quote: "It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits." Wether or not it is a bug I'm really not qualified to say. > > __del__() methods to "do the absolute minimum needed to maintain > > external invariants". See > > http://www.python.org/doc/current/ref/customization.html for more > > information. //Fredrik ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] destructor not getting called?
On Friday 08 November 2002 12:44 am, you wrote: > On Fri, 2002-11-08 at 01:50, Kaleb Pederson wrote: > > I'm using a global QSettings object throughout my application. For some > > reason, when the program closes, the destructor on my QSettings object is > > not getting called. As it is the destructor that actually writes > > everything to disk (in order to cache the data), none of my settings are > > getting saved. Can I manually call it? I'm pretty sure that this used to > > work on previous PyQt/Qt versions. > > The reason you're having problems is most likely because there is no > such thing as a destructor in Python. I assume that you, like many > before you, are treating the __del__() method as a destructor but the > reality is there is no guarantee that __del__() will be called on > program exit. The Python Language Reference recommends that you only use ack, where did you find information implying that __del__ might not get called on program exit? From my understanding, __del__ just wouldn't be called until the reference count reaches 0 and the garbage collection cycle executes. That, of course, should happen for every object at program exit... If it doesn't, that would seem like a Python bug. Greg > __del__() methods to "do the absolute minimum needed to maintain > external invariants". See > http://www.python.org/doc/current/ref/customization.html for more > information. > > //Fredrik > > > ___ > PyKDE mailing list[EMAIL PROTECTED] > http://mats.gmd.de/mailman/listinfo/pykde ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] destructor not getting called?
On Fri, 2002-11-08 at 01:50, Kaleb Pederson wrote: > I'm using a global QSettings object throughout my application. For some > reason, when the program closes, the destructor on my QSettings object is not > getting called. As it is the destructor that actually writes everything to > disk (in order to cache the data), none of my settings are getting saved. Can > I manually call it? I'm pretty sure that this used to work on previous > PyQt/Qt versions. The reason you're having problems is most likely because there is no such thing as a destructor in Python. I assume that you, like many before you, are treating the __del__() method as a destructor but the reality is there is no guarantee that __del__() will be called on program exit. The Python Language Reference recommends that you only use __del__() methods to "do the absolute minimum needed to maintain external invariants". See http://www.python.org/doc/current/ref/customization.html for more information. //Fredrik ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
