Python bindings: Account.getName() raises TypeError

[Geert Janssens]

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] http://docs.python.org/2/library/stdtypes.html

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 
https://github.com/Gnucash/gnucash/commit/b45a9fa874c9dc7da5c81123a5cf8070d9e7fafc

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 
itself.

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 "latex_invoices.py" 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 new_book_with_opening_balances.py 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 https://github.com/Gnucash/gnucash/commit/2215e382

Geert