Python bindings: patch, documentation, examples
jralls at ceridwen.us
Mon Jan 13 18:59:29 EST 2014
On Jan 13, 2014, at 11:14 AM, David Osguthorpe <david.osguthorpe at gmail.com> wrote:
> On Mon, Jan 13, 2014 at 09:23:17AM -0800, John Ralls wrote:
>>> so what should I do with the updates I was proposing to ask you about
>>> eg. no functionality to access budgets in current bindings - I have updates for these
>>> - one issue is that there is no C function to look up budgets by name
>>> - I hacked together a junk python ctypes glib accessor (ctypes is a python module which
>>> allows loading an existing shared library and calling the functions it defines) to access
>>> the list of budget guids that are maintained and then can use the existing budget
>>> list of guids function and write a python function to scan through those looking for a name
>> I think that's exactly the wrong direction to go. GUIDs are an implementation detail that should be private to the engine. Code outside of the engine, including GUI controller code (the 'C' in MVC), should be able to query the database and get an iterator that it can call functions on.
> I agree - it was just a hack to get something working without changing core gnucash
> - I still added the Budget.h into the python bindings for the rest of the budget functions which worked fine
> as a hack didnt want to include it in a suggested patch but without a name lookup for budgets there didnt seem
> to be much point to adding budgets - you can only get a default budget otherwise in the available
> gnc_budget functions
Please remember to copy the list on all replies. Use “reply all” or, if your mailer supports it, “reply list”.
You should use the Query interface to find objects. If there are any “foo_find_by_bar” functions in the API now, they’ll be ripped out in the rewrite. In order to get to multiuser we’ll only be instantiating objects on demand, ideally only to edit unless it turns out to be easier to instantiate for viewing.
More information about the gnucash-devel