[PATCH] Python bindings (with much of the core api)

Derek Atkins warlord at MIT.EDU
Tue Mar 25 10:28:55 EDT 2008

Mark Jenkins <mark at parit.ca> writes:

>> Thanks a lot for submitting these patches! I think everyone here is welcoming 
>> python bindings as new language bindings right in the gnucash trunk branch. 
>> Only nobody has had the time to actually commit those into trunk. But apart 
>> from that, I think as soon as someone commits them, it can directly be worked 
>> upon in trunk.
> Yes, I agree that trunk is fine, as they shouldn't break anything else,
> and I don't plan on breaking the bindings themselves either. Small,
> safe, well tested commits.
> Suggestions of a branch have just been modesty - as I'd rather have
> something here upstream over nothing.
>> Or are you rather asking for actual SVN commit access so that you can feed 
>> back your binding patched into the svn server?
> Once they are in, I would appreciate svn commit access for both Jeff and I.
> We could agree to not make commits that change files outside of
> src/optional/python-bindings, we'll send such patches to the list as usual.
> Further, depending on the nature of the change we would still send many
> changes to the list for audit first, and make the commit ourselves once
> we feel it is acceptable. We can develop some balanced guidelines here,
> and we're willing to learn about the usual balance this community
> follows. We want to be maintainers of this component, but maintainers
> who work with the full community.

In general once we feel comfortable with you as a committer we generally
trust you to commit stuff when you're comfortable with it.  There
really isn't a process in place.  You're welcome to send patches
to the list first, or work on a branch, or just commit it to trunk..

We certainly welcome the python bindings.  I'm just hoping we can
re-use as much of the interface from scheme as possible.  Obviously
that can't necessarily happen, however it might be useful to do
something to make sure that when we add new bindings to scheme you
get them in python, too.

I'm sure SWIG has some way to supply alternate language bindings in
a single interface file.   Looking at your stuff it looks like glib.i
winds up duplicating a lot of work from src/base-typemaps.i and
then later you duplicate a bunch of stuff from src/engine/engine.i

I'm wondering if it makes sense to try to combine them.. or if it
makes sense to keep them separate?  I'm not sure what it would
look like either way.


       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

More information about the gnucash-devel mailing list