[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
[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:15:41 +0100, Till Gerken
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
Re: [PyQt] Re: PyQT lost reference (was: Re: PyKDE: KConfigSkeleton not writing configuration)
On Fri, 13 Mar 2009 11:44:57 +0100, Wolfgang Rohdewald 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 wrote: > On Fri, 13 Mar 2009 11:44:57 +0100, Wolfgang Rohdewald > 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
