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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
