Python bindings: patch, documentation, examples

[John Ralls]

On Jan 13, 2014, at 8:39 AM, David Osguthorpe <david.osguthorpe at gmail.com> 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

Sorry. We've consistently said that on this list.

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

You misunderstand me: Python on its own is a fine language, and I contribute regularly to another project (Gramps) which is a pure-python application. But Python does not excel for extending a program written in another language. It works well to use C and C++ libraries as the basis for a Python program, but Python wants to be in charge. GnuCash is built with Guile in charge, which rather rules out Python taking that role. Guile, for all of its faults, integrates much better with C than does Python and offers a much smaller footprint. This is because Guile was written expressly to be an embedded scripting language and Python was designed to be a general-purpose programming language with scripting bolted on as an afterthought.

The problem with Python on the Mac is that we're supporting 5 versions of OS X, each of which has a different version of libpython.dylib. As I'm sure you know, the python wrappers need to link against that libpython.dylib and be able to dlopen the binary modules that accompany it. That's not a problem for the few folks who build GnuCash themselves, but it's not practical for general distribution. The solution I use for Gramps is to include Python in the app bundle, but that would require that anyone writing GnuCash extensions invoke that python instead of the one in /usr/bin. 

It's even worse on Windows, because we use MinGW, so we'd be linking against the MinGW libpython.dll. Anyone wanting to write Python extensions would have to install the ancient MinGW we use (v11) and run that Python.

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

I think that's exactly the wrong direction to go. GUIDs are an implementation detail that should be private to the engine. Code outside of the engine, including GUI controller code (the 'C' in MVC), should be able to query the database and get an iterator that it can call functions on. 

Regards,
John Ralls