[PyKDE] Implementation of KConfigSkeleton::addItemUInt

[Jim Bublitz]

On Monday 06 September 2004 04:07, Michael Franz Aigner wrote:
> On Wed, 1 Sep 2004 14:14:07 -0700, Jim Bublitz <jbublitz at nwinternet.com> 
wrote:
> Passing a value of Python types like Bool, Int, ... to a function by
> reference and letting the function change the value can not work out,
> because in Python, those types (bool, ...) are by design immutable. Their
> value can not be changed. It does not work in Python code, so IMHO it
> probably can not be translated into C++ code either (by sip, i mean).
> To summarize: I would wish your example would work, but it does not.

OK - the pass by reference in the ctor didn't register with me.

> Rethinking my approach, considering your suggestions, i was able to come up
> with something much simpler, which does not introduce new special classes
> (at least not at the Python level, it still needs some helper classes in
> C++). Here is the patch:
> http://amfranz.com/pykde/PyKDE-3.11.3-kconfigskeleton.diff

Looks OK after a quick look. I'll test it later in the week.

> It removes the 'reference' argument from the argument list of the
> addItemInt/addItemBool/... functions. The functions will allocate the
> reference variable internally, and in a way so it gets freed automatically
> along with the returned KConfigSkeleton.Item* object.

> However, afaik, the *.sip files are are generated by a tool called presip,
> so i guess, so a permanent fix would have to be done in this tool. Am i
> correct in this?

Nope - presip will handle handwritten code. It just needs a "base" sip file 
which already has the handwritten code and will carry it forward to any new 
version. It would also handle the first example you provided too. The 
objection to "special" methods is more in providing bindings that are 
transparent to the Python programmer. I'd like the Python code to look 
exactly like the C++ code, and the code has to be maintained over a long 
period of time too.

The second solution still makes the Python version slightly different, but 
that's often unavoidable when passing references or pointers to basic types. 
It doesn't require new "Python-only" classes or methods however (which is 
sometimes unavoidable too, but I'd like to minimize that).


> I also have a variant which works without declaring any new classes, by
> using placement-new:
> http://amfranz.com/pykde/PyKDE-3.11.3-kconfigskeleton-placement-new.diff

> However, I am not so sure about it, i usually try to avoid placement-new.
> And all this pointer juggling doesn't look like clean code either.

> > It's going to take me some time to work through this, as I don't have any
> > working code that uses KConfigSkeleton, and whatever solution I try, I'd
> > like to be able to test here. I also need to test out the Item<scalar>
> > classes and verify that the Python code (including "casting") works
> > correctly - those might also need some work. It's likely to take some
> > time.

> Mind if i help you a bit? I've made a small test case:
> http://amfranz.com/pykde/kconfigskeleton-test/

That's a big help - thanks.

> It's a small application which displays a configuration dialog with some
> settings to configure, all of which are remembered in
> ~/.kde/share/config/kconfigskeletontestrc

> Off-topic question: I noticed that addItemInt64/addItemUInt64 are declared
> three times in kconfigskeleton.sip, all inside different %If..%End blocks.
> Is there a specific reason for that?

The 64 bit methods in the sip file reference a %MappedType (longlong, 
ulonglong).  When generating a new version, presip effectively merges a newly 
created sip file with the previous version's sip file (the new sip file 
doesn't actually exist prior to merging, but it's basically the same thing). 

It isn't picking up longlong and Q_INT64 as identical types, probably because 
longlong is the mapped type for a "different" type (C++ long long or whatever 
it was implemented for). It thinks it has seen a new method for the new 
version and adds it.  Normally I would correct that manually, but I probably 
wasn't aware it was happening in this case, since it's carried over for 
several versions (I don't read all the code in detail).  

It's a little ugly, but only one of the methods gets selected anyway, so it 
doesn't affect C++ code generation. If %MethodCode is added, that'll need to 
be cleaned up, because the "old" methods will get the method code, but the 
"new" methods won't, unless presip recognizes that they're the same. I could 
probably just give Q_INT64 its own mapped type, or maybe just add a typedef.

I'm going to be away part of this coming week, so it'll probably be next week 
before I can finish this up. I'll put out a new release when it's working.

Thanks for all the work on this!

Jim