python GnuCash interface to SQL backend

Derek Atkins warlord at MIT.EDU
Mon Nov 17 10:01:20 EST 2014

Sébastien de Menten <sdementen at> writes:

> On Fri, Nov 14, 2014 at 3:33 AM, Derek Atkins <warlord at> wrote:
>     John Ralls <jralls at> writes:
>     > What’s your goal here? I don’t think that reimplementing GnuCash in
>     > Python with GnuCash’s SQL schema is a particularly good approach: It’s
>     > not exactly the most efficient design. Rather, it’s designed to mirror
>     > the XML schema. You’ll have a better design if you relegate GnuCash
>     > SQL to import/export.
>     I agree wholeheartedly.  Don't do it this way.  Use the GnuCash Python
>     bindings.  If you don't like the current structure of them, then fix
>     that.  This way your apps will always work because the bindings will
>     stay in lockstep with any changes that get made.
> Hello Derek,
> The GnuCash python bindings are C/SWIG based. This causes some issues on
> windows, and requires deep knowledge of C, SWIG and the GnuCash C api to
> contribute to. 

You're right, it causes issues on windows.  That's because the bindings
are built against a specific version of Python and windows doesn't have
a canonical version.  So we would have to build the wrappers for a
specific version, and possibly even ship it.  Not worth it for the very
few people that actually care about Python on Windows.

As for requiring deep knowledge of C and SWIG, that's completely false.
You need a little knowledge about it, sure.  But if your goal was to
make the Python bindings more Pythonic, I believe you could do that by
wrapping the existing SWIGified APIs with more Pythonic wrappers.  That
would definitely NOT require a "deep knowledge of C" nor "SWIG",
although yes, it would require a deeper knowledge of the GnuCash C API.

> The piecash python bindings are a pure python package ("pip install piecash"
> and you're up and running) and works on the SQL tables through the SQL Alchemy
> library. It is only 500 SLOC today (and may grow in the future but not by an
> order of magnitude). As it is short and in python, it is rather easy to
> contribute/hack/extend.

There's another project, jGnuCashLib, that's a pure Java implementation.
So there is precedent for outside projects to go behind GnuCash's back
to the data file.  However, I don't know if jGnuCashLib is read-write or
read-only.  However there have been issues in that it only implements
the XML backend, doesn't support compression, and has had issues across
GnuCash releases.

I think most of our beef against your project is that you're making it
read-write.  If it was read-only then nobody here would care.


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list