Am 2018-08-06 05:32, schrieb John Ralls:
On Aug 5, 2018, at 5:17 PM, c.holterm...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
