Python bindings: Account.getName() raises TypeError

[David Osguthorpe]

On Sun, Mar 16, 2014 at 08:08:44PM +0100, Felix Schwarz wrote:
> Hey,
> 
> after switching to gnucash 2.6 I noticed that at least some of the Python
> methods are broken [1]. A call to Account.getName() raises a TypeError but
> unfortunately the error message is not helpful to me (as I never used swig
> before):
> TypeError: in method 'xaccAccountGetName', argument 1 of type 'Account const *'

between 2.4 and 2.6 there were a number of changes to the python bindings
- plus a number of raw gnucash functions changed arguments so the bindings
also failed (mainly business) - I also found out as my scripts broke

what Ive discovered is that there is a raw swig instance which maps the
underlying gnucash C object
then there are pythonic wrappers around this raw swig instance
secondly the raw functions are wrapped using the functions in function_class.py
(eg add_constructor_and_methods_with_prefix, method_function_returns_instance etc)
but in a number of cases they are not/missing - in which case the raw swig pointer
object is returned - in others its the pythonic wrapper object - these cannot
be mixed when passed into functions

an example of function I found changed between 2.4 and 2.6 - get_descendants
(note I had already made changes to wrap the original get_descendants to return
Account python objects and called the method GetDescendants in 2.4)

#Account.get_descendants = method_function_returns_instance_list( Account.get_descendants, Account )
# add different name for function
# thats why this fails between 2.4.11 and 2.6.0 - get_descendants now defined
# in main source to return Account objects
# define my original name definitions
#Account.GetDescendants = method_function_returns_instance_list( Account.get_descendants, 
Account )
Account.GetDescendants = Account.get_descendants

same happened to get_children

you can see the swig pointer instance in the python debugger by calling
 get_instance() on eg a python Account object (this class defined in gnucash_core.py)

if you want the pointer to the underlying C object this can be accessed from the
swig instance  as either the __long__() function
(sometimes this is accessed as in data.__long__() )


> - Should I try to get acquainted with swig?

you should understand how gnucash has implemented swig wrapping functions in python
- look at gnucash_core.c, gnucash_core_c.py - the result of applying swig to the
gnucash_core.i swig interface source
then look at gnucash_core.py to see how the pythonic wrappers are placed around
the objects created in gnucash_core_c.py

> - Is it possible the my issue is just Fedora-related (e.g. due to some bad
>   library version)?

dont think so

> - Any hints what could have caused the issue (e.g. bigger swig related
>   changes, core refactorings)?

see above

David