[PyQt] Re: PyQT lost reference (was: Re: PyKDE: KConfigSkeleton not writing configuration)
Hi, sorry for keeping replying to myself, but nobody else seems to show interest and I am trying to find the root cause of the error: The QString() that I am passing as reference to the C++ class KCoreConfigSkeleton exists as local variable in my Python class derived from KCoreConfigSkeleton. Now any code that interacts with KCoreConfigSkeleton (C++ or Python) may change this QString instance. Looking at the SIP file I see the following: KCoreConfigSkeleton::ItemString* addItemString (const QString name, QString reference, const QString defaultValue = QLatin1String(), const QString key = QString()); Could it be that this method declaration misses /In/ and /Out/ for QString reference? The documentation on /In/ and /Out/ was not too clear for me, could someone elaborate what happens exactly when these statements are given? Thanks, Till ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: PyQT lost reference (was: Re: PyKDE: KConfigSkeleton not writing configuration)
On Fri, 13 Mar 2009 11:15:41 +0100, Till Gerken till.ger...@gmail.com wrote: Hi, sorry for keeping replying to myself, but nobody else seems to show interest and I am trying to find the root cause of the error: The QString() that I am passing as reference to the C++ class KCoreConfigSkeleton exists as local variable in my Python class derived from KCoreConfigSkeleton. Now any code that interacts with KCoreConfigSkeleton (C++ or Python) may change this QString instance. Looking at the SIP file I see the following: KCoreConfigSkeleton::ItemString* addItemString (const QString name, QString reference, const QString defaultValue = QLatin1String(), const QString key = QString()); Could it be that this method declaration misses /In/ and /Out/ for QString reference? The documentation on /In/ and /Out/ was not too clear for me, could someone elaborate what happens exactly when these statements are given? By default SIP infers whether an argument is being passed into a function or is only being used to return a value from the function according to the type of the argument. /In/ and /Out/ allow you to be explicit about the direction in case the default behaviour is wrong. For a QString the default is that the argument is being passed into the function. The fact that the string may be being updated doesn't qualify it as being used to return a value in this context. It looks like the omission of any /In/ or /Out/ is correct in this case. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Re: PyQT lost reference (was: Re: PyKDE: KConfigSkeleton not writing configuration)
On Freitag, 13. März 2009, Till Gerken wrote: The QString() that I am passing as reference to the C++ class KCoreConfigSkeleton exists as local variable in my Python class derived from KCoreConfigSkeleton. Now any code that interacts with KCoreConfigSkeleton (C++ or Python) may change this QString instance. this is because QString() is mutable while python strings are immutable. When dealing with KCoreConfig, do not use QString as local variables, always convert explicitly from/to python strings. I wonder what happens with this when the QString will be eliminated in PyQt4 as announced. That might break code which relies on QString being mutable. See my message http://www.mail-archive.com:80/pyqt@riverbankcomputing.com/msg16594.html -- Wolfgang ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: PyQT lost reference (was: Re: PyKDE: KConfigSkeleton not writing configuration)
On Fri, 13 Mar 2009 11:44:57 +0100, Wolfgang Rohdewald wolfg...@rohdewald.de wrote: On Freitag, 13. März 2009, Till Gerken wrote: The QString() that I am passing as reference to the C++ class KCoreConfigSkeleton exists as local variable in my Python class derived from KCoreConfigSkeleton. Now any code that interacts with KCoreConfigSkeleton (C++ or Python) may change this QString instance. this is because QString() is mutable while python strings are immutable. When dealing with KCoreConfig, do not use QString as local variables, always convert explicitly from/to python strings. No, do exactly the opposite. If you pass a Python string then it will be converted to a QString under the covers. Any changes to that QString will then be discarded. I wonder what happens with this when the QString will be eliminated in PyQt4 as announced. That might break code which relies on QString being mutable. Which is why eliminating QStrings is an incompatible change and will require changes to your code. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: PyQT lost reference (was: Re: PyKDE: KConfigSkeleton not writing configuration)
On Freitag, 13. März 2009, Phil Thompson wrote: Which is why eliminating QStrings is an incompatible change and will require changes to your code. Sorry, it seems I misread your roadmap - I thought this would be a compatible change. -- Wolfgang ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: PyQT lost reference (was: Re: PyKDE: KConfigSkeleton not writing configuration)
On 3/13/09, Phil Thompson p...@riverbankcomputing.com wrote: On Fri, 13 Mar 2009 11:44:57 +0100, Wolfgang Rohdewald wolfg...@rohdewald.de wrote: On Freitag, 13. März 2009, Till Gerken wrote: The QString() that I am passing as reference to the C++ class KCoreConfigSkeleton exists as local variable in my Python class derived from KCoreConfigSkeleton. Now any code that interacts with KCoreConfigSkeleton (C++ or Python) may change this QString instance. this is because QString() is mutable while python strings are immutable. When dealing with KCoreConfig, do not use QString as local variables, always convert explicitly from/to python strings. No, do exactly the opposite. If you pass a Python string then it will be converted to a QString under the covers. Any changes to that QString will then be discarded. The weird thing in this case is that the changes made by KCoreConfigSkeleton are discarded. Even if I call KCoreConfigSkeleton::ItemString::setValue(), the referenced QString is not updated (although it will then be written to disk correctly). This suggests that two instances of the same QString exist. I can live with the workaround calling KCoreConfigSkeleton::ItemString::setValue() and getValue(), but I wonder where the bug is. Any pointers would be appreciated. Till ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
