python GnuCash interface to SQL backend

[Derek Atkins]

Sébastien de Menten <sdementen at gmail.com> writes:

> On Monday, November 17, 2014, Derek Atkins <warlord at mit.edu> 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

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