Python bindings: Account.getName() raises TypeError

Geert Janssens janssens-geert at
Wed Mar 19 12:35:00 EDT 2014

On Tuesday 18 March 2014 07:28:56 John Ralls wrote:
> My point is that Python barely knows about type at all, except for its own built-in types [1]. It 
will raise a TypeError if you try to divide a string, like this:
> >>> 'foo' / 3
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for /: 'str' and 'int'
> or dereference an index of something that isn't a sequence and so on. Otherwise it blithely 
tries to do what you ask it, raising an AttributeError if you try to dereference a non-existant 
class member, which includes calling a function that the object's class doesn't have:
> >>> 'foo'.framish()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AttributeError: 'str' object has no attribute 'framish'
> Python doesn't have a way to declare type arguments to a function, so
> it can't raise a TypeError if an argument is the wrong type: It has
> no way of knowing. One can write code like this: if not
> isinstance(foo, 'Account'):
>      raise TypeError("foo is a %s which is not a subclass of Account"
> % type(foo))
> But it's rare to see that in live code. It's considered more
> "Pythonic" to try to do what you want and handle the exception if it
> fails.
> Regards,
> John Ralls
> [1]

David Osguthorpe has provided the correct solution earlier in this thread:

for child in original_parent_account.get_children():
    original_account = Account(instance=child)

Should become 
for child in original_parent_account.get_children():
    original_account = child

The issue is not with Account const * vs const Account * in swig. Swig basically ignores const 
correctness (that's a documented "feature"). The issue was that Account(instance=child) 
assumes child is of type "SwigPyObject", which it no longer is since

I committed that change on behalf of Hendrik Van Antwerpen. I didn't realize then the change 
broke some of our example scripts. So not an external swig change after all, but one in gnucash 

I have fixed this particular example and scanned the other ones as well, adding a few more 
similar fixes. There may still be similar issues with other object types. I have only looked for 
Account so far.

I didn't change the "" example. It seems to have some nice type checking 
code that may make the script run successfully on both 2.4 and 2.6. I say "may" because I 
haven't tested it.

In addition I fixed the script to properly deal with non-
currency commodity accounts. It would just abort if it found one. Now it properly creates the 
commodity and account in the new book.
Fixes in


More information about the gnucash-devel mailing list