[GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)

[c.holtermann at gmx.de]

Am 2018-08-06 05:32, schrieb John Ralls:
>> On Aug 5, 2018, at 5:17 PM, c.holtermann at gmx.de wrote:
>> 
>> Hello,
>> 
>> after some time I get back to the gnucash python bindings.
>> 
>> I worked on a str method for GncNumeric. It's in the example_script
>> dir 
>> (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_scripts/str_methods.py)
>> I changed it to python3. Then I began to wonder about the 
>> relationshipp of
>> the SwigObject and the wrapping object.
>> 
>> In this case it's something like
>> <gnucash.gnucash_core_c._gnc_numeric; proxy of <Swig Object of type 
>> '_gnc_numeric *' at 0x7f11908da840> >
>> and
>> <gnucash.gnucash_core.GncNumeric object at 0x7f118f76d6d8>
>> 
>> When I have the GncNumeric object I can access the SwigObject through 
>> its instance property.
>> The other way round seems not as simple.
>> 
>> My method __gncnumeric__str__ overwrites the __str__ method using 
>> add_method.
>> 
>> In this method self points to the swig object. I cannot use the 
>> methods of GncNumeric as
>> it is the layer of the wrapping object.
>> 
>> To access these methods I used to instantiate a 
>> GncNumeric(instance=self) as a temporary self.
>> But that seems not right as this probably already exists.
>> 
>> I wondered if I could know about the wrapping object when I had the 
>> instance only. I did not
>> find a way. I stumbled over an interesting comment in
>> https://github.com/Gnucash/gnucash/blob/69fef8277fde56e7d2df700b21c63c19c115852a/bindings/python/function_class.py#L50
>> 
>> # why reimpliment __new__? Because later on we're going to
>> # use new to avoid creating new instances when existing instances
>> # already exist with the same __instance value, or equivalent 
>> __instance
>> # values, where this is desirable...
>> 
>> I did not find "later on". But if that works I can safely do 
>> GncNumeric(instance=self) as it
>> would reuse the existing GncNumeric object.
>> 
>> But nevertheless I wondered if we could put a link to the GncNumeric 
>> in the Swig Level. I tried
>> it:
>> https://github.com/c-holtermann/gnucash/commit/a6c2adf7d29c4367728a4fa920307ee595eefa5a
>> (link to my fork)
>> 
>> Interstingly some Swig objects can be added to and some others not. 
>> GncNumeric works while
>> QofSession doesn't. So I made it a try block for now.
>> 
>> Having done that I can get to the GncNumeric (sort of higher self) 
>> from the Swig object:
>> https://github.com/c-holtermann/gnucash/commit/2f35b550709ad4131aca0e7309f6bb4b0f984b84
>> 
>> Well I found it interesting to think these things through. Maybe 
>> someone can tell me about
>> the mysterious "later on" in the cited comment. At this point I find 
>> it useful to have a
>> way from the instance to the wrapping object through some kind of link 
>> as I suggested in
>> the patch to function_class.
> 
> Christoph,
> 
> The person who wrote the first two lines of that, Mark Jenkins, was
> the original source of the Python bindings. He was never a regular
> dev, he just got 16 patches committed between 2007 and 2012, 10 of
> which touched the python bindings. Your history with them is almost as
> long as his--in fact you have *12* commits--and pretty much no one
> else has done anything serious with them.
> 
> In other words, if anyone knows, it’s you!
> 
> Just to add some more confusion, there’s now a C++ class GncNumeric
> that handles the actual implementation of many of the gnc_numeric.*
> functions. I believe that SWIG can’t see it, only the C wrapper
> functions are exposed to SWIG.
> 
> Regards,
> John Ralls

John,

thank you for the insights and the friendly words. I like the python 
bindings
for gnucash and use them to feed my bank data to gnucash using a 
webscraping
script that fetches a CSV for me which I can then import using the 
bindings.
This has worked quite well for me for years. At some point in time 
gnucash
wouldn't build due to some segmentation error. The system was working 
but I
only now came back to compile gnucash again when I made a big system 
update.

I'm willing to now and then do something for the python bindings. I 
don't feel
like an expert. But surely I'd like to talk and think things through 
about
them. Maybe someone is interested. I saw that there were some people 
asking
questions about the bindings on this list. Maybe they don't commit but 
still
work with the bindings. So my question remains and maybe someone has an 
idea.
I will continue to think about it anyway (depending on the time I can 
spare
on this project :-).

I thought I will look through the python bindings and see if all files 
are
compatible with python3. Thanks to you developers who made that step for
the bindings ! I suppose some of the example scripts are not yet 
converted.
The information in the wiki should reflect the step to python3. I'll try 
to
have a look at that.

Then you speak of c++ GncNumeric. As I understand you are moving the 
source
from c to c++. So the python bindings need to reflect that. That sounds 
like
another piece of work. Is there imminent need for change there ? Chances 
of
breaking changes ?

regards,

Christoph Holtermann