Python bindings: patch, documentation, examples

David Osguthorpe david.osguthorpe at
Mon Jan 13 11:39:36 EST 2014

On Sun, Jan 12, 2014 at 08:14:11PM -0800, John Ralls wrote:
> > * Who is maintaining the Python bindings and is there any roadmap to
> > improve them?
> They're maintained enough to keep them compiling by the core team. They're not
> really part of our development plan, they're mostly just there.

This is not good news to me - Ive been playing with these for my personal accounting
eg updating stock prices, currencies - to take into account the vagaries of finance-quote
failing in various ways - and unable to do currency histories - so can do a bulk
update of prices every so often

> > IMHO the Python bindings are a really great way of enhancing the GnuCash
> > functionality without having to code C/C++ (I would not be very
> > productive with it...)
> Unfortunately Python isn't a very good built-in scripting language, and supporting
> it on Mac and Windows is a serious PITA. Guile is better, except the number of 
> Scheme programmers loose in the world is pretty small. For the foreseeable future
> I'd expect that any code accepted into GnuCash itself will have to be C/C++ or Scheme,
> with a very strong preference for C++.

I dont understand why you would say this - Im using a lot of code with python
(and Im on a Mac mainly also Linux - use gnucash via macports) in a lot of
 very different code systems eg pymol, ffmpeg)
I have a very hacky implementation in gnucash to call python from guile and
return results to guile - I found existing libraries to do both
(no updates to gnucash required - just a user prototype.scm file)
- was trying to look at ways to write reports in python
pygtk gives access to gtk functions (and glib) so you could write gnucash GUI in python
(Ive actually re-written the gnome solitaire games program from guile into python as a learning
as you say guile is a pain so there are few experts in it -
and I have tried it (I made a multi-stock price scatter plot base on the single stock price scatter)
- but Im using python in so many more cases trying to have 2 languages doesnt make sense

> > I will properly write more code in the near future using the Python
> > bindings --- I would also gladly help extending/improving the current
> > code base and/or documentation :-)
> Rather than extending the current wrappers, I think we need to work out a reasonable
> public API that properly hides the implementation. The current policy of "open kimono"
> would be a serious constraint on further development if there was a bunch of external
> code that we had to be worried about not breaking. The way some of the code flips back and 
> forth between C and Scheme is pretty bad already.

I agree - I looked into how to write gnucash in python (the gtk functions are the same
so can eg directly read the existing ui xml files) but found that scheme/guile is not
only used to write reports but also plays an intermediary role in some of the GUI elements

so what should I do with the updates I was proposing to ask you about
eg. no functionality to access budgets in current bindings - I have updates for these
- one issue is that there is no C function to look up budgets by name
- I hacked together a junk python ctypes glib accessor (ctypes is a python module which
allows loading an existing shared library and calling the functions it defines) to access
the list of budget guids that are maintained and then can use the existing budget
list of guids function and write a python function to scan through those looking for a name


More information about the gnucash-devel mailing list