python GnuCash interface to SQL backend

Derek Atkins warlord at MIT.EDU
Tue Nov 18 10:15:18 EST 2014

Sébastien de Menten <sdementen at> writes:

> On Monday, November 17, 2014, Derek Atkins <warlord at> wrote:
>     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.
> Yes indeed. Me first needs are a) to read a GnuCash boom from python and b) to
> create some new objects (accounts, commodities, transactions & splits,
> prices).  This is what is implemented and works today. 
> Updating/deleting existing objects is delicate as is the creation of more
> complex business objects (relying on the kvp) -> not in scope 

The problem is that you cannot skip this complexity, because you run the
risk of creating an object that fails the unwritten gnucash data
invariants.  There are expected data entries that gnucash makes and will
cause... confusion... if they are not there.  (E.g. the date in the kvp)

> So I should have say that it is a CR (not UD) interface to GnuCash books. 

R is fine.  C, U, and D are dangerous.

I still encourage you to make the SWIG python bindings more pythonic and
use that instead of trying to reverse-engineer the gnucash business
logic, especially if you want C, U, and D.

> Sebastien


       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