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

[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