Python bindings: patch, documentation, examples

John Ralls jralls at ceridwen.us
Sun Jan 12 23:14:11 EST 2014


On Jan 12, 2014, at 11:22 AM, Henning Jacobs <henning at jacobs1.de> wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I recently discovered the great Python bindings and just updated
> http://wiki.gnucash.org/wiki/Python_Bindings to contain pointers to my
> scripts.
> 
> Now my questions:
> 
> * GncPrice does not contain a proper __init__, therefore I monkey
> patched it:
> https://github.com/hjacobs/gnucash-stock-portfolio/blob/master/gnucash_patch.py
> --- What's the best way to make a patch request for the original GnuCash
> Python bindings?

File a bug with the patch attached: http://wiki.gnucash.org/wiki/Git#Patches

> * Are there any other known/major users of the Python bindings?

Not as far as I know

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

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

Regards,
John Ralls




More information about the gnucash-devel mailing list