Python bindings: patch, documentation, examples

[Geert Janssens]

On Monday 13 January 2014 08:39:36 David Osguthorpe wrote:
> 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
> 
You could volunteer to maintain/improve the bindings (no long-term commitment required) :)

Seriously, GnuCash is a volunteer effort and none of the current developers is using the python-
bindings much. Which results in the state John mentions. That's not to say they aren't nice to 
have. But it would help if someone was willing to spend some effort on it.

> > > 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)

IIRC OS X ships its own versions of python and each OS X release ships a different version. But 
the python bindings have to be compiled against the version that it will be used with. For 
Macports that's probably not an issue. It is for the OS X/Quarz version of GnuCash, which is 
available for download on the GnuCash website. That version can only support one version of 
python, and hence will only work on one OS X release.

For Windows, python isn't even officially available. We'd have to resort to an installer available 
somewhere on the web. The official python on Windows is not compatible with Mingw, which 
we have based or Windows build on. Additionally if we start depending on python for GnuCash 
that would mean we'd have to add python to the windows installer, which would make it a *lot* 
bigger. It's already a large download as it is currently.

> 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
Impressive !

> 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 exercise)
For your personal use I'd say great!
For the core of gnucash however it's currently not even clear if gtk will remain on our long-term 
roadmap. It's based on gobject which originally seemed like a good plan for portability. But 
developments in the last few years have been working against it. For example it has long not 
been possible to easily build gtk3 on Windows. Trying to port it to more extremely different 
platforms such as IOS or Android is near impossible (for completeness: support for those 
platforms are *not* on the roadmap, but I prefer to keep future options as open as possible).

There have been several discussions in the (recent) past about the cost/benefit of switching to 
another gui framework (both Qt and WxWidgets are good potential candidates). Again this is a 
long-term goal at best. The first priority is to clean up the core api and rewrite it to C++.

> 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
Agreed. Guile is more prominently present currently because gnucash once started off as a 
guile application. C has been added later and has gradually been replacing parts of guile. 
Python came much later still, but was never part of the core.

> > > 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
> 
Which I hope we eventually get rid of.
> 
> so what should I do with the updates I was proposing to ask you about
I would still accept these updates if they can remain optional. Improving the api can be done in 
parallel.

> 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
A few questions on this approach:
- Budgets is not my area, but are budget names required to be unique by the way ?
- Wouldn't it be easier to write a c function that looks up a budget by name and then wrap that 
function ?
- And can't qof be used to query budgets by name ?

Geert