Sébastien de Menten <sdemen...@gmail.com> writes:
> On Monday, November 17, 2014, Derek Atkins <warl...@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
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
